💪REST API 설계 원칙

- REST: URI를 통해 자원을 표시하고, HTTP Method를 이용하여 해당 자원의 행위를 규정하여 그 결과를 받는 것을 의미한다.

- REST API: REST를 기반으로 서비스 API를 구현한 것을 의미한다.

- 자원(URI), 행위(HTTP 표현 메서드), 표현(페이로드)의 세가지 요소로 구성됨

 

👊 REST의 특징

1) Uniform:  URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍쳐 스타일을 의미한다.

2) Stateless: 작업을 위한 상태정보를 따로 저장하고 관리하지 않으며, 서버로 들어오는 요청만 단순히 처리하면 된다.
3) Cacheable: HTTP라는 기존 웹 표준을 그대로 사용하고 있기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용할 수 있다. 따라서 HTTP가 가진 캐싱 기능을 사용할 수 있다.

4) Self-descriptiveness: REST API 메시지만 보고도 이를 쉽게 표현할 수 있는 자체 표현 구조로 되어있다.

5) Client - Server 구조: REST서버는 API 제공, 클라이언트는 사용자 인증이나 세션, 로그인 정보 등을 직접 관리하는 구조로 각각의 역할을 확실하게 구분한다.
6) 계층형 구조: REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조 상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있게 한다.

 

👊 REST API 설계 원칙

 

1.URI는 리소스를 표현해야한다.  

- 동사보다는 명사를 사용해야한다.

- 행위에 대한 표현이 들어가서는 안된다. 리소스를 표현하는데 중점을 둔다.

 

2.리소스에 대한 행위는 HTTP 요청 메서드로 표현한다.

- 클라이언트가 서버에게 요청의 종류와 목적을 알리는 방법

- GET, POST, PUT, PATCH, DELETE 등을 사용하여 CRUD를 구현

 

GET: 리소스에서 모든 정보를 취득한다.

POST: 해당 리소스에 서버로 전송한 페이로드를 생성한다.

PUT: 특정 리소스 전체를 교체할때 사용한다.

PATCH: 특정 리소스의 일부만 교체할 때 사용한다.

DELETE: 리소스의 id를 사용하여 특정 리소스를 삭제한다.

 

ex) DELETE /member/1 , GET /member/delete/1 등