Ch03. HTTP 메서드

1. HTTP API

URI = Uniform Resource Identifier → 가장 중요한 것은 리소스 식별!!!

리소스 = 회원이라는 “개념” 자체 → 회원 리소스를 URI에 매핑!!!

** 계층 구조 상 상위를 컬렉션으로 보고 복수 단어 사용 권장 ex) member → members

리소스와 행위를 분리해야 함 → URI와 Method

 

 

2. HTTP 메서드 - GET, POST

GET : 리소스 조회

• 서버에 전달할 데이터는 query를 통해 전달
• 메시지 바디 사용 가능하지만, 권장 X

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

• 메시지 바디를 통해 서버로 요청 데이터 전달
• 주로 신규 리소스 데이터 등록, 프로세스 변경(요청 데이터 처리.. control URI), 다른 메서드로 처리하기 애매한 경우
• 리소스 URI에 POST 요청이 오면 요청 데이터 처리를 리소스마다 따로 정함

기타 메서드

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

 

 

3. HTTP 메서드 - PUT, PATCH, DELETE

1) PUT : 리소스 완전히 대체 → 해당 리소스가 없으면 생성

• 클라이언트가 리소스 위치를 정확히 알고 URL 지정

2) PATCH : 리소스 부분 변경 → 사용 불가할 경우 POST로 대체

3) DELETE : 리소스 삭제

 

4. HTTP 메서드 속성

1) 안전(Safe)

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

2) 멱등(Idempotent)

• 몇 번을 호출하든 결과가 동일 → GET, PUT, DELETE
• POST는 여러 번 호출 시 같은 데이터가 여러 개 누적해 생성될 수 있음
• 자동 복구 메커니즘 → 서버가 TIMEOUT 등 정상 응답 못할 경우, 클라이언트가 동일한 요청 반복 가능
• 외부 요인으로 인한 중간 리소스 변경은 고려 X

3) 캐시 가능(Cacheable)

• 응답 결과 리소스를 캐시해서 사용 가능 여부
• 실제로는 GET, HEAD 정도만 캐시로 사용
• POST, PATCH는 본문 내용까지 캐시 키로 사용해야 하기 때문에 권장 X

 

 

5. 클라이언트 → 서버 데이터 전송

1) 데이터 전송 방식

(1) 쿼리 파라미터

• 주로 GET 메소드
• 주로 정렬 필터나 검색어 등에 사용

(2) 메시지 바디

• 주로 POST, PUT, PATCH 메소드
• 주로 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 등에 사용

 

2) 4가지 상황

(1) 정적 데이터 조회

• 이미지, 정적 텍스트 문서
• 조회는 GET 메소드 사용
• 쿼리 파라미터 미사용 → 단순한 리소스 경로로 조회 가능

(2) 동적 데이터 조회

• 검색, 정렬 필터 등
• 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건
• 조회는 GET 메소드 사용
• 쿼리 파라미터 사용해 데이터 전송

(3) HTML Form을 통한 데이터 전송

• HTML의 form tag 사용 → 웹 브라우저가 요청 http 메시지 생성
• method = “post”
  • Content-Type: application/x-www-form-urlencoded → form 내용을 메시지 바디를 통해 전송(key-value), 전송 데이터 url 인코딩 처리
  • 입력 내용은 http 메시지 body
• method = “get”
  • 입력 내용을 쿼리 파라미터로 변경
• Content-Type: multipart/form-data → 다른 종류의 여러 파일과 form 내용 함께 전송

(4) HTML API를 통한 데이터 전송

• 클라이언트에서 서버로 바로 데이터를 전송해야 하는 경우 → 서버 to 서버, 앱, 웹(js를 통한 통신)
• Content-Type: application/json 주로 사용 → text, xml, json
• post, put, patch, get 모두 사용 가능

 

6. HTTP API 설계 예시

API URI 설계는 리소스 기반으로 작성할 것!!

(1) 회원 관리 시스템 - POST

• 클라이언트는 등록될 리소스의 URI를 모름
• 서버가 새로 등록된 리소스 URI를 생성해 Location 필드로 응답
• 컬렉션 : 서버가 관리하는 리소스 디렉터리 → 서버가 리소스의 URI를 생성하고 관리

 

(2) 파일 관리 시스템 - PUT

• 클라이언트가 리소스 URI를 알고 있어야 함
• 클라이언트가 직접 리소스의 URI를 지정
• 스토어 : 클라이언트가 관리하는 리소스 저장소 → 클라이언트가 리소스의 URI를 알고 관리

 

(3) HTML FORM 사용

• GET, POST만 지원
• 컨트롤 URI : 메소드 제약을 해결하기 위해 동사로 된 리소스 경로 사용