HTTP API

API URI의 설계는 가장 중요한건 리소스의 식별이다.

 

리소스의 의미는 무엇일까.

회원을 등록,수정,조회하는것 자체는 리소스가 아니다.

회원이라는 개념 자체가 바로 리소스.

 

등록(create),수정(update),조회(read),삭제(delete)라는것은 일단 배제하고, 회원이라는 리소스만 식별하면 된다.

 -> 즉 무엇을 대상으로(리소스) 어떠한 행동을 하는건지를 생각해보면 쉽다.

 

그럼 URI는 리소스만 식별한다고 했으니 설계를 해보면 /members/{id}. 가 되겠는데, 이것만으로 어떻게 행위를 구분할 수 있을까. 이럴때 추가로 사용되는게 바로 http 메소드(GET,POST,PUT,DELETE..)

 -> 리소스와 행위를 분리하는 것.

 

라고는 하지만, 실제 모든 경우에 대해서 URI와 행위를 분리를 깔끔하게 분리가능한 경우가 없을 수 있음.

 -> POST /orders/{orderId}/start-delivery -> start-delivery라는 동사가 uri에 포함이 됨. 이런걸 컨트롤URI라고한다.

HTTP 메소드

 - GET : 리소스를 조회.

  -> request-line인 쿼리스트링에 담긴다. -> 보통 검색에 사용

  -> GET에도 메시지 바디를 사용해서 데이터 전달이 가능하긴 하지만 권장x

 - POST :  요청한 데이터를 처리

   -> HTTP 요청의 바디에 데이터가 담긴다.

   -> 서버는 클라이언트가 요청한 데이터를 처리.

   -> 가장 다양한 행위의 의미를 포함. post 메소드의 URI요청이 오면 해당 요청 데이터를 어떻게 처리할지 정해야함.

    --> 값의 등록,변경을 넘어 어느 프로세스의 상태변경에도 포함.

 - PUT : 리소스를 대체, 해당 리소스가 없다면 생성.

  -> 리소스가 있으면 완전히 대체하고 없으면 생성한다. (덮어버리기 기능. 수정의 기능이 아님!)

  -> POST와 비슷해보이지만, POST는 등록의 요청에서 많이쓰이기때문에 리소스 식별위치를 정확히 모르는 경우가 많은데, PUT은 리소스를 식별하고 URI를 지정함.

  -> 즉. 해당 URI 위치에 해당하는 리소스를 대체 혹은 생성을 한다는 것.

 - PATCH : 리소스 부분 변경

  -> PUT이 리소스를 완전히 대체한다고 했는데, 기존의 id,pwd등의 필드가 있었고, PUT 요청으로 pwd 필드만 담아서 보내면 id는 사라지고 pwd 필드만 남게 된다.

  -> 이럴 때 사용하는게 PATCH. 리소스의 부분 변경을 하는 것. (수정(UPDATE)의 기능)

 - DELETE : 리소스 삭제

  -> 리소스를 제거할 때 사용.

 

그럼 이제 URI와 HTTP메소드를 통해 리소스와 행위의 분리가 가능해진다.

GET

 

POST 

URI에 정확한 리소스 위치가 식별되어있진 않음.

POST는 201 Created 상태코드를반환하고, 리소스가 생성된 경로를 넣어서 반환.

PUT

URI에 리소

PATCH

age 20을 50으로 수정한다.

 

DELETE

해당 URI에 해당하는 리소스를 삭제한다.

 

정리

URI는 리소스만 식별.

행위 : 조회,등록,삭제,변경등과 같은 것은 HTTP 메소드를 이용

URI와 행위를 분리. 

 

HTTP 메소드의 속성

안전(Safe Methods)

멱등(Idempotent Methods)

캐시가능(Cacheable Methods)

 

HTTP메소드의 속성에는 위 3가지가 존재한다.

 

안전(SAFE)

호출해도 리소스를 변경하지 않는다. -> GET등. 단순 조회이므로.

여기서 안전의 대상은 리소스만을 의미함. (클라이언트의 폭발적인 GET요청에 대한 장애등을 말하는게 아님)

 

멱등(Idempotent)

멱등이란 의미를 위키백과에서 검색해보았는데

 

멱등법칙 또는 멱등성은 수학이나 전산학에서 연산의 한 성질을 나타내는 것으로, 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미한다. 

 

즉 호출한 횟수와는 관계없이, 그 결과는 변하지 않음을 의미한다.

GET : 한번이든 여러번이든 같은 결과를 조회한다.

PUT : 같은 요청을 여러번 해도, 요청하는 값은 동일하므로 여러번 호출하던 결과는 일 (PUT은 결과를 대체한다는걸 잊으면안됨)

DELETE : 같은 요청을 여러번해도, 삭제된 결과는 같음.

POST : 멱등이 아니다. 두 번 호출시 같은 결제가 중복해서 발생할 수 있다.

 

멱등이란것의 활용은 자동 복구 메커니즘에 있다.

 -> 흔히 우리가 웹에서 버튼을 눌렀는데 응답이 없으면 여러번 누르는 것 처럼.

 

멱등이란 개념은 중간에 리소스가 변경되는것까지 고려하지 않음.

사용자 1 : GET -> OrderID:ASDF, OrderName:abcd
사용자 2 : PUT -> OrderID:ZXCV, OrderName:abcd
사용자 1 : GET -> OrderID:ZXCV, OrderName:abcd

즉 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 않고,

오직 나(클라이언트)만이 동일한 요청을 했을 때 변하지 않는다는것을 의미.

 

캐시가능(Cacheable)

응답 결과 리소스를 캐시해서 사용해도 되는가를 의미.

GET,HEAD,POST,PATCH는 캐시가능하지만 실제로는 GET,HEAD정도만 캐시로 사용한다고 한다.

 -> POST,PATCH는 본문 내용까지 캐시 키로 고려해야하는데 구현이 쉽지않다고 함.

 

섹션5는 비공개 게시물로 작성예정

 

출처 - 김영한님 강의 (https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC)