HTTP 메서드

요구사항

회원 정보 관리 API

- 회원 목록 조회

- 회원 조회

- 회원 등록

- 회원 수정

- 회원 삭제

 

 

API URI(Uniform Resource Identifier) 고민

리소스란?

- 회원을 등록하고 수정하고 조회하는 것이 리소스가 아님

- 회원이라는 개념 자체가 리소스!

 

리소스를 어떻게 실별?

- 회원을 등록하고 수정하고 조회하는 것을 모두 배제

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

 

 

API URI 설계

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

- 회원 목록 조회/members

- 회원 조회/members/{id}

- 회원 등록/members/{id}

- 회원 수정/members/{id}

- 회원 삭제/members/{id}

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

- 어떻게 구분?

 

 

리소스와 행위를 분리

가장 중요한 것은 리소스를 식별하는 것!

- URI는 리소스만 식별!

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

ex)

리소스 : 회원

행위 : 조회, 등록, 삭제, 변경

 

- 리소스는 명사, 행위는 동사

- 행위(메서드)는 어떻게 구분? -> HTTP 메서드 학습 필요

 

 

 

 

HTTP 메서드 - GET, POST, PUT, PATCH, DELETE

클라이언트가 서버에게 무언가를 요청할 때, 기대하는 행동

 

 

HTTP 메서드 종류

주요 메서드

- GET : 리소스 조회

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

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

- PATCH : 리소스 부분 변경

- DELETE : 리소스 삭제

 

 

GET

- 리소스 조회

- 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)을 통해서 전달 ex) spring에서 @RequestParam 사용

- 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음

 

ex)

요청(클라이언트 -> 서버)

GET /members/100 HTTP/1.1

Host: localhost:8080

 

확인(서버)

/members/100

{

    "username":"young",

    "age":20

}

 

응답(서버 -> 클라이언트)

HTTP/1.1 200 OK

Content-Type: application/json

Content-Length: 34

{

    "username":"young",

    "age":20

}

 

 

POST

- 요청 데이터 처리

- 메시지 바디를 통해 서버로 요청 데이터 전달 ex) spring에서 @RequestBody 사용

- 서버는 요청 데이터를 처리

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

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

 

 

ex)

리소스 등록1 - 메시지 전달(클라이언트 -> 서버)

POST /members HTTP/1.1

Content-Type: application/json

{

    "username": "young",

    "age": 20

}    

 

리소스 등록2 - 신규 리소스 생성(서버)

/members/100

{

    "username":"young",

    "age":20

}

 

리소스 등록3- 응답 데이터(서버 -> 클라이언트)

HTTP/1.1 201 Created

Content-Type: application/json

Content-Length: 34

Location: /members/100

{

    "username":"young",

    "age":20

}

 

POST 정리

1. 리소스 생성(등록)

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

 

2. 요청 데이터 처리

- 단순히 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우

- ex) 주문 결제 완료 -> 배달 시작 -> 배달 완료처럼 단순히 값 변경을 넘어서 프로세스의 상태가 변경되는 경우

- POST의 결과로 새로운 리소스가 생성되지 않는 경우도 존재

- ex) POST /orders/{orderId}/start-delivery (컨트롤 URI)

 

3. 다른 메서드로 처리하기 애매한 경우

- ex) JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우 존재

- 애매하면 POST 사용

 

 

PUT

1. 리소스를 대체

- 리소스가 있으면 대체

- 리소스가 없으면 생성

- 쉽게 이야기해서 덮어버림

 

2. 중요! 클라이언트가 리소스를 식별

- 클라이언트가 리소스 위치를 알고 URI 지정 (/members/100)

- POST와 차이점 (/members) vs (/members/100)

 

리소스가 있는 경우1(클라이언트 -> 서버)

PUT /members/100 HTTP/1.1

Content-Type: application/json

{

    "username": "old",

    "age": 50

}    

 

리소스가 있는 경우2 - 리소스 대체 (서버)

/members/100

{

    "username":"old",

    "age":50

}

 

 

리소스가 없는 경우1(클라이언트 -> 서버)

PUT /members/100 HTTP/1.1

Content-Type: application/json

{

    "username": "old",

    "age": 50

}    

 

리소스가 없는 경우2 - 신규 리소스 생성 (서버)

/members/100

{

    "username":"old",

    "age":50

}

 

 

주의! - 리소스를 완전히 대체1

PUT /members/100 HTTP/1.1

Content-Type: application/json

{

    "age": 50

}

 

기존 데이터

/members/100

{

    "username": "young",

    "age": 20

}

 

주의! - 리소스를 완전히 대체2 (기존 데이터 없애고, 리소스 대체 -> username 필드 사라짐)

{    

    "age": 50

}

 

※ PUT은 수정 목적이 아니라 완전히 새로운 값으로 대체하는 목적. 수정하려면? -> PATCH 사용

 

 

PATCH

- 리소스 부분 변경

 

리소스 부분 변경1 (클라이언트 -> 서버)

PATCH /members/100 HTTP/1.1

Content-Type: application/json

{

    "age": 50

}    

 

기존 데이터 (서버)

/members/100

{

    "username":"young",

    "age":20

}

 

리소스 부분 변경2 - 리소스 부분 변경(서버 -> 클라이언트)

/members/100

{

    "username":"young",

    "age":50

}

 

 

DELETE

- 리소스 제거

 

리소스 제거1(클라이언트 -> 서버)

DELETE /members/100 HTTP/1.1

Host: localhost:8080

 

기존 데이터 (서버)

/members/100

{

    "username":"young",

    "age":20

}

 

리소스 제거2 (서버)

리소스 제거

/members/100

 

 

 

HTTP 메서드의 속성

- 안전(Safe Methods)

- 멱등(Idempotent Methods)

- 캐시가능(Cacheable Methods)

 

안전(Safe)

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

- Q: 그래도 계속 호출해서, 로그 같은게 쌓여 장래가 발생?

- A: 안전은 해당 리소스만 고려, 거기까지 고려 X

 

 

멱등(Idempotent)

- f(f(x)) = f(x)

- 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같음

- 멱등 메서드

1. GET : 한 번 조회하든, 두 번 조회하든 같은 결과가 조회됨

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

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

4. POST : 멱등 X. 두 번 호출하면 같은 결제가 중복해서 발생 가능

- Q: 재요청 중간에 다른 곳에서 리소스를 변경하면?

사용자1: GET -> username:A, age:20

사용자2: PUT -> username:A, age:30

사용자1: GET -> username:A, age:30 -> 사용자2의 영향으로 바뀐 데이터 조회

 

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

 

 

 

캐시 가능(Cacheable)

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

- GET, HEAD, POST, PATCH 캐시 가능

- 실제로는 GET, HEAD 정도만 캐시로 사용

- POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현 어려움

 

 

 

출처 : https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC