HTTP 메서드

HTTP API를 만들어보자

요구사항- 회원 정보 관리 API를 만들어라

1. 회원 목록 조회

2. 회원 조회

3. 회원 등록

4. 회원 수정

5. 회원 삭제

 

API URI 고민

회원 등록 수정 조회하는것이 리소스가 아니다. 회원이라는 개념 자체가 리소스다

그러면 리소스는 어떻게 식별하는 것이 좋을까?

 

회원을 등록하고 수정하고 조회하는 것을 모두 배제시킨다.

회원이라는 리소스만 식별하면 된다 -> 회원 리소스를 URI에 매핑

 

API URI 설계- 리소스 식별, URI 계층 구조 활용

1. 회원 목록 조회: /members

2. 회원 조회: /members/{id}

3. 회원 등록: /members/{id}

4. 회원 수정: /members/{id}

5. 회원 삭제: /members/{id}

참고: 계층 구조상 상위를 컬렉션으로 보고 복수단어 사용 권장(member -> members)

 

리소스와 행위를 분리하라

- URI는 리소스만 식별한다

- 리소스와 해당 리소스를 대상으로 하는 행위를 분리

리소스는 회원이고, 행위는 조회 등록 삭제 변경이다.

- 리소스는 명사고 행위는 동사라고 생각하자 

---

HTTP 메서드- GET, POST

HTTP 메서드는 클라이언트가 서버에 무언갈 요청할 때 기대하는 행동이다

 

HTTP  주요 메서드 종류

- GET: 리소스 조회

- POST: 요청 데이터 처리, 주로 등록

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

- PATCH: 리소스 부분 변경

- DELETE: 리소스 삭제

 

GET

- 리소스 조회

- 서버에 전달하고 싶은 데이터는 query parameter를 통해서 전달

- 메세지 바디를 사용해서 데이터 전달 가능하긴한데 권장 X

 

리소스 조회1- 메세지 전달

 

리소스 조회2- 서버 도착

 

리소스 조회3- 응답 데이터

 

POST

- 요청 데이터 처리

- 메세지 바디를 통해 서버로 요청 데이터 전달 

- 서버는 메세지 바디를 통해 들어온 데이터를 처리하는 모든 기능 수행

- 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리함

 

리소스 등록1- 메세지 전달

post로 /members 라는곳에 전달한다

 

리소스 등록2- 신규 리소스 생성

서버에서 이 데이터를 받아서 열어보고 데이터베이스에 등록하고 신규아이디를 만들고 

신규 리소스 식별자를 생성한다

 

리소스 등록3- 응답 데이터

 

POST는 요청 데이터를 어떻게 처리한다는 뜻일까?

POST 메서드는 대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청한다

 

POST는 다음과 같은 기능에 사용된다

 

- HTML 양식에 입력된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공

        예) HTML FORM에 입력한 정보로 회원가입, 주문 등에서 사용

- 게시판, 뉴스 그룹, 메일링 리스트, 블로그 등에 메세지 게시

        예) 게시판 글쓰기, 댓글 달기

- 서버가 아직 식별하지 않은 새 리소스 생성

        예) 신규 주문 생성

- 기존 자원에 데이터 추가

        예) 한 문서 끝에 내용 추가하기

 

리소스 URI에 POST 요청이 오면, 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야한다

-> 정해진 것이 없다!

 

정리하자면

1. 새 리소스 생성(등록)

 

2. 요청 데이터 처리 

- 단순히 데이터 생성 변경을 넘어, 프로세스를 처리해야 하는 경우를 말한다

예를 들어 결제완료 -> 배달시작 -> 배달완료 처럼 프로세스 상태가 변경되는 경우

- POST의 결과로 새로운 리소스가 생성이 안될 수도 있다

예를 들어 POST/orders/{orderID}/start-delivery (컨트롤 URI)

 

3. 다른 메서드로 처리하기 어려운 경우

예를 들어 JSON으로 조회 데이터를 넘겨야 되는데, GET을 사용하기 어려운 경우

애매하면 POST를 쓴다

 

---

HTTP 메서드- PUT, PATCH, DELETE

PUT

- 리소스가 있으면 대체, 없으면 생성

- 쉽게 말하면 덮어버린다

- 중요한건 클라이언트가 리소스 위치를 알고 URI를 지정한다 -> POST와 차이점

 

리소스가 있는 경우

/100을 지정하고 서버로 날라가면 100번이 이미 있다

 

그러면 대체가 된다

주의할 점은 기존 리소스를 삭제하고 완전히 대체한다는 점이다.

그래서 수정하는 것이 어렵다. 수정하는 의도로 사용하려면 PATCH를 사용

리소스가 없는 경우

 

PATCH

- 리소스 부분 변경

 

DELETE

- 리소스 제거

 

---

HTTP 메서드의 속성

 

안전(Safe)

- 호출해도 리소스를 변경하지 않는다

 

멱등(Idempotent)

- 한 번이든 두 번이든 100번이든 호출의 결과가 똑같다

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

- PUT: 결과를 대체한다. 그러므로 같은 요청을 여러번 해도 최종 결과는 같다.

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

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

- 멱등은 외부 요인으로 중간에 리소스 변경되는 것까지는 고려 X

 

캐시가능(Cacheable)

- 응답 결과 리소스를 캐시해서 사용해도 되는가?

- GET, HEAD 정도를 캐시로 사용