REST는 Representational State Transfer의 약자, 로이필딩에 의해 만들어짐
앱 사이의 결합도를 낮추게끔 설계하는 아키텍처 스타일로
서버와 클라이언트가 별도로 구축되고 결합될 수 있게 함
🍀 REST API
자원을 이름으로 구분하여 자원의 상태를 주고받는 방식
- HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
- HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해
- 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미합니다.
🍀 Richardson Maturity Model
리차드슨이 정의한 REST API의 성숙도 모델
대개는 4가지를 모두 만족하지 않고, Resource와 HTTP Verb만 도입하는 수준으로 사용
0. HTTP 사용
단일 URI과 HTTP 프로토콜 메소드를 사용 (아주 기본적인 단계)
1. URI Resource
리소스 개념을 도입하여, 모든 요청을 하나의 endpoint로 보내는 것이 아니라 개별 리소스와 통신함
- HTTP method는 get, post만 사용
- StatusCode는 200만으로 전달
- header에 Content-Type이나 Cache 정보도를 제공하지 않는 단계
2. HTTP Verbs
4가지 HTTP method를 사용해서 CRUD를 표현하는 단계
- StatusCode를 다양하게 활용함
- header에 Content-Type이나 Cache 정보를 제공함
- 보통 2단계까지만 수행함
3. Hypermedia Controls
API 서비스의 모든 End-point를 최초 진입점이 되는 URI를 통해 Hypertext Link 형태로 제공
- 클라이언트가 요청에 응답받은 후, 다음 단계의 작업을 알려주는 링크 요소를 제공하는 것
🍀 REST API 설계 기본 규칙
동사 사용 X (행위는 HTTP method로 표현)
URL은 리소스 그 자체를 표현해야하고, CRUD 행위는 HTTP method로 표현되야함
- 나쁜 예:
/read-posts→ url에 행위가 표시되어 있음 - 좋은 예:
/posts→ 리소스 자체, 이걸로 get 요청을 하면 포스트 읽기가 됨
HTTP method
Create와 Update는 요청시 JSON으로 데이터 전달함
- Read - GET
- Create - POST
- Update - PUT(전체)/PATCH(일부)
- Delete - DELETE
Collection/Document/Store/Controller
- Collection : 단일 리소스(Document)들의 묶음 (복수)
ex)http://<host>/poducts - Document: Collection내의 단일 리소스 (단수)
ex)http://<host>/poducts/1상품의 아이디가 1인 경우 - Store: 클라이언트 쪽에서 저장하는 리소스 저장소 (보통 복수)
ex)http://<host>/users/2/carts2번 유저의 장바구니 or 위시리스트 - Controller: CRUD를 제외한 특정 기능 요구시 예외적으로 동사 표현 허용
ex)http://<host>/users/2/register
이외 URL Rules
- 마지막에
/를 포함하지 않음 _대신-사용- 소문자 사용