HTTP/HTTP 메서드

• API URI 설계

 

• 회원 목록 조회/read-member-list

• 회원 조회/read-member-by-id

• 회원 등록/creat-member

• 회원 수정/update-member

• 회원 삭제/delete-member

 

이것은 좋은 URI 설계가 아니다. 가장 중요한 것은 리소스 식별이다. 리소스는 회원이라는 개념 자체가 리소스다. 읽기, 생성하기, 업데이트하기, 삭제하기가 리소스가 아님(동사가 아닌 명사여야 함) -> 즉, 회원이라는 리소스만 식별하면 된다.(회원 리소스를 URI에 매핑)

 

• 회원 목록 조회/member

• 회원 조회/members/{id}

• 회원 등록/members/{id}

• 회원 수정/members/{id}

• 회원 삭제/members/{id}

리소스와 행위를 분리해야한다. URI는 리소스만 식별한다. 그렇다면 행위는? -> 행위는 HTTP메서드를 이용하면 됨.

 

• GET: 리소스 조회

서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달한다. 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음

 

• POST: 요청 데이터 처리, 주로 등록에 사용

메시지 바디를 통해 서버로 요청 데이터 전달하고 서버는 들어온 요청 데이터를 처리함한다. 주로 데이터를 이용해서 신규 리소스 등록, 프로세스 처리에 사용함. 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 함.

 

• PUT: 리소스를 대체, 해당 리소스가 없으면 생성

리소스가 있으면 대체하고, 리소스가 없으면 생성한다. 쉽게 이야기해서 덮어버림. PUT /members/100 HTTP/1.1처럼 클라이언트가 리소스 위치를 알고 URI를 지정함.

 

• PATCH: 리소스 부분 변경

리소스를 완전 다 바꾸지 않고,  일부만 변경한다. 예를 들어서 username과 age가 있는데 age만 바꾸고 싶으면 바꿀 수 있음 PUT과 비교해볼 것

 

• DELETE: 리소스 삭제

리소스를 삭제할 수 있다.

 

• HTTP 메서드의 속성

 

• 안전: 호출해도 리소스를 변경하지 않는다. 리소스(자원)에 영향을 미치지 않는다는 뜻인 듯. 계속 호출했을 때, 로그가 쌓여 장애가 생겨도 

안전은 해당 리소스만 고려하는 것임.

 

• 멱등: 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다. 자동 복구 메커니즘에 활용됨. 서버가 TIMEOUT 등으로 정상 응답을 못 주었을 대, 클라이언트가 같은 요청을 다시해도 되는가?의 판단 근거로도 활용이 됨. 만약 재요청 중간에 다른 곳에서 리소스를 변경해버리는 경우에는 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지는 않는다. 즉, 리소스가 변경이 되더라도, 멱등은 멱등인 듯

 

• GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.

• PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.

• DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.

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

 

 

• 캐시가능: 응답 결과 리소스를 캐시해서 사용해도 되는가? GET, HEAD, POST, PATCH 캐시 가능함. 실제로는 GET, HEAD 정도만 캐시로 사용한다. POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음