HTTP 메서드

Web Infra

HTTP 메서드

작은별._. 2023. 12. 7. 21:38

728x90

API URI 만들기

URI를 만드는 데에 있어 가장 중요한 것은 리소스를 식별하는 것
예시) 회원 관리 API를 만들 때, 아래와 같은 API 필요
- 회원 목록 조회
- 회원 조회
- 회원 등록
- 회원 수정
- 회원 삭제

여기서 리소스는 회원이라는 개념 자체이다.
이 리소스를 어떻게 식별해야 할까?
- 회원이라는 리소스만 식별하면 된다.(id) → 회원 리소스를 URI에 mapping
- 회원 목록 조회: /members
- 회원 조회: /members/{id}
- 회원 등록: /members/{id}
- 회원 수정: /members/{id}
- 회원 삭제: /members/{id}
- 참고로, 계층 구조상 상위를 컬렉션으로 보고 복수단어 사용 권장 (member X, members O)
위의 리소스 식별된 각각의 URI들을 각 행위(조회, 등록, 삭제, 변경)에 맞게 구분 필요 → 리소스(명사)와 행위(동사)를 분리하자!!
URI는 리소스(회원)만 식별
행위는 어떻게 구분?
- HTTP 메서드로 구분하자

HTTP 메서드

주요 메서드

GET: 리소스 조회
POST: 요청 데이터 처리, 주로 등록에 사용
PUT: 리소스 전체 대체, 해당 리소스가 없으면 생성
PATCH: 리소스 부분 변경
DELETE: 리소스 삭제

기타 메서드

HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
CONNECT: 대상 리소스로 식별되는 서버에 대한 터널을 설정
TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수

참고로, 최근에는 Resource라는 용어 대신, Representation이라는 용어 사

GET

리소스 조회
서버에 전달하고 싶은 데이터는 query(쿼리 파라미터/스트링) 통해 전달
메시지 바디를 사용해 데이터 전달 가능하지만, 지원하지 않는 곳이 많아 권장하지 않음

POST

요청 데이터 처리
메시지 바디를 통해 서버로 요청 데이터 전달
서버는 요청 데이터 처리
- 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능 수행
주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
- 새 리소스 생성(등록): 서버가 아직 식별하지 않은 새 리소스 생성
- 요청 데이터 처리: 단순히 데이터 생성/변경하는 것을 넘어 프로세스 처리해야 하는 경우
  - 즉, POST 결과로 새로운 리소스가 생성되지 않을 수 있음
  - 주문에서 결제완료 배달시작 배달완료 처럼 단순히 값 변경을 넘어 프로세스 상태를 제어하여 변경하는 경우
    - POST /orders/{orderId}/start-delivery
- 다른 메서드로 처리하기 애매한 경우
  - ex) JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드 사용이 어려운 경우
  - 애매하면 POST

PUT

리소스 대체
- 리소스가 있으면 대체
- 리소스가 없으면 생성
- 즉, 완전히 덮어쓰기
- member의 username, age 속성이 있는데, (부분 변경하고 싶어) age 속성만 명시하여 PUT 하면 username은 사라진다!! (완전히 대체!!)
  - 부분 변경하고 싶으면 PATCH 사용
클라이언트가 리소스 식별
- 클라이언트가 리소스 위치를 알고 URI 지정
- POST와 차이점
  - PUT /members/100 : 특정 위치를 지정 (클라이언트가 위치를 알고 있어야 한다.)
  - POST /members : 어디 위치에 만들어질지 모름

PATCH

리소스 부분 변경

DELETE

리소스 삭제

HTTP 메서드 속성

안전(Safe Methods)

호출해도 리소스가 변경되지 않는다.
안전은 리소스만 고려한다. 해당 리소스가 변하냐 변하지 않냐만 고려하여 '안전하다'라고 한다.

멱등 (Idempotent)

f(f(x)) = f(x)
한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 동일
멱등 메서드
- GET: 조회, 무조건 결과 동일
- PUT: 결과 대체, 같은 요청을 여러 번 해도 최종 결과는 동일
- DELETE: 결과 삭제, 같은 요청을 여러 번 해도 삭제된 결과는 동일
- POST: 멱등이 아니다! 두 번 호출하면 같은 프로세스(결제, 배달 등)가 중복해서 발생 가능
활용: 자동 복구 메커니즘
- 서버가 TIMEOUT 등으로 정상 응답을 못 주었을 때, 클라이언트가 같은 요청을 반복해서 해도 되는가? 판단할 때 사용
멱등은 외부 요인으로 중간에 리소스가 변경되는 것까지는 고려하지 않는다.

캐시 가능 (Cacheable)

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

API 설계

POST 기반

회원 목록 조회: /members → GET
회원 등록: /members → POST
회원 조회 : /members/{id} → GET
회원 수정: /members/{id} → PATCH, PUT, POST
회원 삭제: /members/{id} → DELETE

PUT 기반

파일 목록 /files → GET
파일 조회 /files/{filename} → GET
파일 등록 /files/{filename} → PUT
파일 삭제 /files/{filename} → DELETE
파일 대량 등록 /files → POST

POST 기반은 클라이언트가 서버에게 등록 요청하여 서버가 알아서 리소스 URI를 내려주는 방식이고 (Collection - 컬렉션 방식), PUT 기반은 클라이언트가 리소스 URI를 알고 직접 관리하는 방식 (Store - 스토어 방식)

실무에서는 거의 POST를 사용

HTML FORM 사용

GET, POST만 사용 가능

회원 목록 조회: /members → GET
회원 등록 폼: /members/new → GET
회원 등록: /members/new, /members → POST
회원 조회: /members/{id} → GET
회원 수정 폼 : /members/{id}/edit→ GET
회원 수정 : /members/{id}/edit, /members/{id} → POST
회원 삭제: /members/{id}/delete → POST
- GET, POST만 지원하는 제약으로 인해 어쩔 수 없이 new, edit, delete를 리소스 경로에 사용해야 한다. (동사로 된 경로) → 컨트롤 URI
- 회원 등록이나 수정에서 POST의 URI는 GET과 동일한 것으로 설정하는 것이 좋다. (/members/new, /members/{id}/edit)

URI 설계 개념

문서(document)
- 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)
- 예) /members/100, /files/star.jpg
컬렉션(collection)
- 서버가 관리하는 리소스 디렉터리
- 서버가 리소스의 URI를 생성하고 관리
- 예) /members
스토어(store)
- 클라이언트가 관리하는 자원 저장소
- 클라이언트가 리소스의 URI를 알고 관리
- 예) /files
컨트롤러(controller), 컨트롤 URI
- 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
- 동사를 직접 사용
- 예) /members/{id}/delete

[출처]

김영한, "모든 개발자를 위한 HTTP 웹 기본 지식", 인프런

728x90