Representational State Transfer
- 웹상에서 사용되는 여러 리소스를 HTTP URI로 표현하고 그 리소스에 대한 행위를 HTTP Method로 정의하는 방식
- 리소스(HTTP URI로 정의된)를 어떻게 한다를 구조적으로 깔끔하게 표현
장점 : self-descriptiveness
RESTful API는 그 자체만으로도 API의 목적이 쉽게 이해 된다.
단점 : 표준규약이 없어, 안티패턴으로 작성되는 경우가 흔하다
기본 배경 지식
URI : 해당 사이트의 특정 자원의 위치를 나타내는 유일한 주소
HTTP Method : HTTP request가 의도하는 acrion을 정의한 것
payload : HTTP request에서 server로 보내는 데이터 (body)
설계 규칙
- URI 정보를 명확하게 표현
=> resource는 명사를 사용한다.
(Ex.GET/users/1) - resource에 대한 행위를 HTTP MEthod
(GET, POST, PUT, DELETE)로 표현한다.
=> URI에 HTTP Method가 포함되서는 안된다.
(Ex. GET delete/user/1 -> DELETE/users/1)
=> URI에 동사가 포함되서는 안된다.
(Ex. GET/user/show/1 -> GET/users/1) - resource사이에 연관 관계가 있는 경우
=> /리소스/고유ID/관계 있는 리소스
(Ex. GET/users/{user_id}/profile) - 파일의 경우 payload의 포맷을 나타내기 위한 파일 확장자를 URI에 포함시키지 않는다
(Ex. GET user/1/profile-photo.jpg
=> 이때, payload의 포맷은 headers에 accept를 사용한다) - URI는 / 구분자를 사용하여 자원의 계층 관계를 나타내는데 사용
- URI 마지막 문자로 /를 포함하지 않는다
- 불가피하게 URI가 길어질 경우 ' - '를 사용하여 가독성을 높인다.
- ' _ ' 는 사용하지 않는다
- URI 경로에는 대문자 사용을 피하도록 규정
Query parameter - Filtering
- 필터
Query parameter - Ordering
- 정렬
Query parameter - Pagination
- 몇 개만 불러올 때 사용
Query parameter - Searching
Best Practice : Filtering, Sorting, Searching
Status Code
공부하며 정리&기록하는 ._. 씅로그
Front-end