리소스(HTTP URI로 정의된)를 어떻게 한다를 구조적(HTTP Method + Payload)으로 깔끔하게 표현
Representational State Transfer : 무언가 상태를 나타내는 것을 보내준다. 누가봐도 자명하게 명확하게 나타낸다.
API 시스템을 구현하기 위한 아케틱쳐 중(ex. Graphql ,SOAP, GRPC, REST)에 가장 널리 사용되는 형식
"프론트엔드에서 백엔드 API를 호출할 url을 어떻게 만들것인가?"
장점
단점
URI/HTTP Method/Payload
URI
: 해당 사이트의 특정 자원의 위치를 나타내는 유일한 주소HTTP Method
: HTTP request가 의도하는 action을 정의한 것Payload
: HTTP request에서 server로 보내는 데이터(body)1. URI 정보를 명확하게 표현해야 한다.
: resource는 명사를 사용한다.
: 무조건 복수로 사용하자!!!
❌ GET/user/1
⭕️ GET/users/1
2. resource에 대한 행위를 HTTP Method로 표현한다.
: URI에 HTTP 메서드가 포함되어서는 안된다.
❌ GET delete/user/1
⭕️ DELETE/users/1
3. URI에 동사가 포함되어서는 안된다.
: URI는 명사여야 한다.
❌ GET/user/show/1
⭕️ GET/users/1
❌ POST insert/user/2
⭕️ POST/users/2
4. 파일의 경우 payload의 포맷을 나타내기 위한 파일 확장자를 URI에 포함시키지 않는다.
❌ GET user/1/profile-photo.jpg
⭕️ GET user/1/profile-photo
(이때 payload의 포맷은 헤더스에 어셉트를 사용한다.)
5. URI는 / 구분자를 사용하여 자원의 계층 관계를 나타내는데 사용한다.
6. URI 마지막 문자로 /를 포함하지 않는다.
❌ GET users/portfolios/
7. 불가피하게 URI가 길어지는 경우 -을 사용하여 가독성을 높인다.
8. _는 사용하지 않는다.
9. URI 경로에는 대문자 사용을 피하도록 규정하고 있다.
update를 위해 PUT || PATCH를 사용 / GET || POST의 차이 블로그 쓰기
Filtering
Ordering
Pagination
모범 답안은 있으나 정답은 없으니 개발 맥락에 따라 유연하게 사용하자!
Path parameter
: 단 하나의 상품만 가져오는 경우 사용한디.(정수값을 받아올 수 있기 때문)
Query parameter
: Filtrering, Sorting, Searching일 때 사용한다.
개발자는 각자 1인분을 만드는 것이 아니라 서로가 모여 1인분을 만드는 직업이다.