# 섹션6. HTTP 메서드 활용

## 1. 클라이언트에서 서버로 데이터 전송

### 데이터 전달 방식은 크게 2가지&#x20;

* 쿼리 파라미터를 통한 데이터 전송&#x20;
  * GET
  * 주로 정렬 필터(검색어)
* 메시지 바디를 통한 데이터 전송
  * POST, PUT, PATCH
  * 회원 가입, 상품 주문, 리소스 등록, 리소스 변경

### 4가지 상황&#x20;

#### 정적 데이터 조회&#x20;

* 이미지, 정적 텍스트 문서&#x20;
* 조회는 GET 사용&#x20;
* 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능&#x20;

<figure><img src="https://2093748731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQMqxl0iBPcO3zyZX5B19%2Fuploads%2FsObyQIHenJ8ZnudEknXO%2F%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-06-06%2008.58.24.png?alt=media&#x26;token=94bb5774-4503-4ab8-b8fc-96fc0ca54f12" alt=""><figcaption></figcaption></figure>

#### 동적 데이터 조회&#x20;

* 주로 검색, 게시판 목록에서 정렬 필터(검색어)
* 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용
* 조회는 GET 사용&#x20;
* GET 은 쿼리 파라미터를 사용해서 데이터를 전달&#x20;

<figure><img src="https://2093748731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQMqxl0iBPcO3zyZX5B19%2Fuploads%2F3MGbmwwanwCaFk3yu4qt%2F%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-06-06%2008.59.11.png?alt=media&#x26;token=35f333e7-9292-4f76-a71e-332bde1fd753" alt=""><figcaption></figcaption></figure>

#### HTML Form 을 통한 데이터 전송&#x20;

* HTML Form submit시 POST 전송
  * 예) 회원 가입, 상품 주문, 데이터 변경
* Content-Type: application/x-www-form-urlencoded 사용&#x20;
  * form 의 내용을 메시지 바디를 통해서 전송(key=value, 쿼리 파라미터 형식)&#x20;
  * 전송 데이터를 url encoding 처리&#x20;
    * abc김 - > abc%EA%B9%80
* HTML Form 은 GET 전송도 가능&#x20;
* Content-Type: multipart/form-data
  * 파일 업로드 같은 바이너리 데이터 전송시 사용&#x20;
  * 다른 종류의 여러 파일과 폼의 내용 함께 전송 가능(그래서 이름이 multipart)&#x20;
* **참고 : HTML Form 전송은 GET, POST 만 지원**&#x20;

<figure><img src="https://2093748731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQMqxl0iBPcO3zyZX5B19%2Fuploads%2FVqFoicTOKyEffOekDvLD%2F%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-06-06%2009.02.00.png?alt=media&#x26;token=0c72e9a0-4a20-4504-9943-4bf84bbd7348" alt=""><figcaption></figcaption></figure>

<figure><img src="https://2093748731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQMqxl0iBPcO3zyZX5B19%2Fuploads%2Fd5kEfMZADX4NV4HrJsxM%2F%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-06-06%2009.02.09.png?alt=media&#x26;token=c5c34df9-e5c5-45b5-8013-3ea871a87ea9" alt=""><figcaption></figcaption></figure>

<figure><img src="https://2093748731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQMqxl0iBPcO3zyZX5B19%2Fuploads%2Fi0ogc0uO1GikBo9zTLtn%2F%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-06-06%2009.02.20.png?alt=media&#x26;token=cb9db307-c6da-4ac3-80da-007beeaab9df" alt=""><figcaption></figcaption></figure>

<figure><img src="https://2093748731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQMqxl0iBPcO3zyZX5B19%2Fuploads%2FzAoUXSvsNkSm0eyYUB21%2F%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-06-06%2009.07.49.png?alt=media&#x26;token=c5a27e1a-067e-4d46-a9ae-659c568a916f" alt=""><figcaption></figcaption></figure>

#### HTML API 를 통한 데이터 전송&#x20;

* 회원 가입, 상품 주문, 데이터 변경
* 서버 to 서버&#x20;
  * 백엔드 시스템 통신&#x20;
* 앱 클라이언트&#x20;
  * 아이폰, 안드로이드&#x20;
* 웹 클라이언트&#x20;
  * HTML 에서 Form 전송 대신 자바 스크립트를 통한 통신에 사용 (AJAX)&#x20;
  * 예) React, VueJs 같은 웹 클라이언트와 API 통신&#x20;
* POST, PUT, PATCH : 메시지 바디를 통해 데이터 전송&#x20;
* GET : 조회, 쿼리 파라미터로 데이터 전달&#x20;
* Content-Type: application/json 을 주로 사용 (사실상 표준)
  * TEXT, XML, JSON 등등.. &#x20;

<figure><img src="https://2093748731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQMqxl0iBPcO3zyZX5B19%2Fuploads%2Fvsa1Lhm1adOLf6FvGJ1a%2F%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202025-06-06%2009.17.56.png?alt=media&#x26;token=88efb115-a4cd-4e5b-89ce-cbb2141b1eb2" alt=""><figcaption></figcaption></figure>

## 2. HTTP API 설계 예시&#x20;

### HTTP API - 컬렉션&#x20;

#### 회원 관리 시스템 (API 설계 - POST 기반 등록)&#x20;

* 회원 목록 /members -> **GET**
* 회원 등록 /members -> **POST**
* 회원 조회 /members/{id} -> **GET**
* 회원 수정 /members/{id} -> **PATCH, PUT(override), POST**
  * 일반적으로는 PATCH 를 사용해 부분적으로 수정하지만,&#x20;
  * 게시판 수정 같이 덮어 쓸 수 있는 경우 PUT 을 사용해 수정한다.
  * 하지만, 애매한 경우는 POST 를 사용해서 수정할 수 있다.
* 회원 삭제 /members/{id} -> **DELETE**

#### 회원관리 시스템 (POST - 신규 자원 등록 특징)&#x20;

* **클라이언트는 등록될 리소스의 URI 를 모른다.**&#x20;
  * 회원 등록 /members -> POST&#x20;
  * POST /members&#x20;
* 서버가 새로 등록된 리소스 URI 를 생성해준다.&#x20;
  * HTTP/1.1 201 Created \
    **Location: /members/100**
* 컬렉션 (Collection)
  * 서버가 관리하는 리소스 디렉토리&#x20;
  * 서버가 리소스의 URI 를 생성하고 관리&#x20;
  * 여기서 컬렉션은 /members

### HTTP API - 스토어&#x20;

#### 파일 관리 시스템 (API 설계 - PUT 기반 등록)&#x20;

* 파일 목록 /files -> **GET**
* 파일 조회 /files/{filename} -> **GET**&#x20;
* 파일 등록 /files/{filename} -> **PUT**&#x20;
  * 파일의 경우 덮어쓰는 과정이 적합하기 때문에 PUT 을 사용한다.&#x20;
* 파일 삭제 /files/{filename} -> **DELETE**&#x20;
* 파일 대량 등록 /files -> **POST**

#### **파일 관리 시스템 (PUT - 신규 자원 등록 특징)**&#x20;

* 클라이언트가 리소스 URI 를 알고 있어야 한다.&#x20;
  * 파일 등록 /files/{filename} -> PUT&#x20;
  * PUT /files/star.jpg&#x20;
* 클라이언트가 직접 리소스의 URI 를 지정한다.&#x20;
* 스토어(Store)&#x20;
  * 클라이언트가 관리하는 리소스 저장소&#x20;
  * 클라이언트가 리소스의 URI 를 알고 관리&#x20;
  * 여기서 스토어는 /files

### HTML FORM 사용&#x20;

* HTML FORM 은 GET, POST 만 지원&#x20;
* AJAX 같은 기술을 사용해서 해결 가능 -> 회원 API 참고&#x20;
* 여기서는 순수 HTML, HTML FORM 이야기&#x20;
* GET, POST 만 지원하므로 제약이 있음&#x20;

#### HTML Form 기반 회원 관리 시스템 (API 설계)&#x20;

* 회원 목록 /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**

#### HTML Form 기반 회원 관리 시스템 (특징)

* HTML Form 은 GET, POST 만 지원&#x20;
* 컨트롤 URI&#x20;
  * GET, POST 만 지원하므로 제약이 있음&#x20;
  * 이런 제약을 해결하기 위해 **동사로** 연결된 리소스 경로 사용&#x20;
  * POST 의 /new, /edit, /delete 가 컨트롤 URI&#x20;
  * HTTP 메서드로 해결하기 애매한 경우 사용 (HTTP API 포함)&#x20;

> #### 주의 - 컨트롤 URI
>
> **일단은 리소스를 기반으로 HTTP URI 를 설계한 후, 안될 때 대체제로 컨트롤 URI 를 사용해야만 한다!**&#x20;
>
> 그렇지 않을 경우 일관성 없는 HTTP URI 를 설계한다..&#x20;

### 참고하면 좋은 URI 설계 개념

<https://restfulapi.net/resource-naming/>

#### 문서(document)&#x20;

* 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)&#x20;
* ex, /members/100, /files/star.jpg

#### 컬렉션(collection)&#x20;

* 서버가 관리하는 리소스 디렉토리&#x20;
* 서버가 리소스의 URI 를 생성하고 관리
* ex, /members

#### 스토어(store)&#x20;

* 클라이언트가 관리하는 자원 저장소&#x20;
* 클라이언트가 리소스의 URI 를 알고 관리&#x20;
* ex, /files&#x20;

#### 컨트롤러(controller), 컨트롤 URI&#x20;

* **문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행** \
  **-> 실무에서는 자주 발생한다.**
* 동사를 직접 사용&#x20;
* ex, /members/{id}/delete
