위코드 파운데이션 과정을 들으며 정리한 내용입니다.

REST API 란

REST API 란 REST 하게 API를 서술하는 방법입니다. REST 는 Representational State Transfer 의 약자로 상태를 전달하는 방법을 의미합니다. 통신이란 특정 자원(데이터)를 어떤 방식으로 전달하는 것으로 이를 더 원활하게 하고자 REST 와 같은 방법들이 생겨나게 됩니다. (http 로 어느정도 통일했지만, 이를 조금 더 개선하고자)

정보를 요청할 때는 what 와 how 로 요청할 수 있는데, 여기서 what(무엇) 은 특정 데이터를 resource 라 부르며 URI (Uniform Resource Identifier) 로 표협합니다. how 는 어떻게 하겠다는 동사이고, http methoud 로 표현합니다. (URL 과 URI 는 다릅니다. URL 은 URI 에 포함된 서브셋으로 URI 는 식별하고, URL 은 위치를 가르킵니다.)

REST API 의 장점

가장 명확한 장점은 self-descriptiveness 입니다. 리소스와 메소드만 보고 API 의 목적을 이해할 수 있습니다.

[GET] http://localhost:8000/users - 유저 정보를 얻는다.
[GET] http://starbucks.com/beverages/1 - 스타벅스 1번 음료 정보를 얻는다.
[POST] http://starbucks.com/order-body{beverage:2} - 스타벅스 2번 음료를 주문한다.

RESTful API 설계 원칙

REST 는 설계 규칙으로 일반적으로 통용되는 규칙이 있습니다.

Uniform Interface

요청을 진행할 대상(URI)은 정확하게 명사로 지칭합니다.

[GET]/find/users/1 -> [GET]/users/1

Resource 에 대한 행위는 HTTP method 가 하므로 동사를 제거합니다.

[DELETE] /delete/users/1 -> [DELETE] /users/1

Resource 사이의 연관 관계 및 계층 관계가 있을 경우 슬래쉬 / 를 사용합니다.

[GET] /users/{user_id}/profile 

URI 가 길어질 경우 - 를 사용해 가독성을 높입니다. 언더바를 사용하면 하이퍼 링크의 디폴트 밑줄에 가려질 수 있습니다.

[GET] /users/1/ordered-items

응답 Response 의 status code 기본 규칙 들

200 OK - Success - GET : 리소스 반환, PUT/PATCH : 상태 메시지 또는 리소스 반환
201 Created - Success - POST : 상태 메시지 또는 새로 생성된 리소스 반환
204 No Content - Success - DELETE : 성공적으로 삭제된 요청의 응답
400 Bad Request - Falilure - ALL : 요청에 잘못된 값 포됨
401 Unauthorized - Falilure - ALL : 인증 요청했으니 사용자가 인증 조건 충족 못함
403 Forbidden - Falilure - ALL : 사용자가 허용되지 않은 콘텐츠로 접근 시도
404 Not Found - Faillure - ALL : 리소스 없음
405 Method Not Allowed - Falilure - All : 허가되지 않은 HTTP Method로 시도됨
..