[HTTP] HTTP 메서드 활용 | 정적 / 동적 데이터 | HTML Form | HTTP API

 

클라이언트에서 서버로 데이터 전송하는 방식은 크게 두 가지이다.

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

 

그럼, 클라이언트에서 서버로 데이터가 전송되는 4가지 상황을 생각해보자.

 

1. 정적 데이터 조회 - 이미지, 정적 텍스트 문서

2. 동적 데이터 조회 - 검색, 게시판 목록에서 정렬 필터(검색어)

3. HTML Form을 통한 데이터 전송 - 회원 가입, 상품 주문, 데이터 변경

4. HTTP API를 통한 데이터 전송 - 회원 가입, 상품 주문, 데이터 변경 (서버 to 서버, 앱 클라이언트, 웹 클라이언트)

 

1. 정적 데이터 조회

정적 데이터를 조회할 때는 쿼리 파라미터를 사용하지 않는다.

조회이므로 HTTP 메서드는 GET을 쓰면 된다.

GET /static/star.jpg HTTP/1.1
Host: localhost:8080

 

클라이언트가 /static/star.jpg라는 경로로 별 이미지를 조회하는 상황이라면, 서버는 클라이언트에게 해당 리소스를 내려준다.

여기서 이미지 리소스를 만들어서 내려줄 뿐, 별다른 쿼리 파라미터가 필요없다.

위처럼 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회할 수 있다.

 

2. 동적 데이터 조회

동적 데이터를 조회할 때는 쿼리 파라미터를 사용해야 한다.

 

 

동적 데이터를 조회한다는 것은 주로 검색이나 게시판 목록에서 정렬 필터를 사용한다는 것이다.

(검색어를 입력해서 조회)

조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에서 주로 사용한다.

GET은 쿼리 파라미터를 사용해서 데이터를 전달하게 된다.

 

 

3. HTML Form 데이터 전송

 

3.1) POST 전송

 

HTML 폼이 넘어가는 것이다. 요청 메시지에서는 urlencoded인 HTML 폼이 넘어간다는 것이 Content-type에 명시되어 있다.

 

Content-Type을 보자.
이 부분을 "url encoding"이라고 하는데, 데이터를 application/x-www-form-urlencoded 방식으로 변환하는 것을 의미한다.
ex) 예: username=kim&age=20처럼 키-값 쌍이 &로 연결된 형식.
이 방식은 폼 데이터를 간단하게 표현하며, 브라우저는 폼 데이터를 자동으로 이 방식으로 인코딩하여 서버로 전송한다.

 

여기서 method는 당연히 POST이다. GET을 써서 /save?username=kim&age=20 이런식으로 HTML Form을 작성해버리면 당연히 리소스가 저장되지 않는다.

 

3.2) GET 조회

 

HTML Form을 사용해 리소스를 조회할 때는 GET 메서드를 사용하도록 주의하자.

 

3.3) Multipart/form-data

 

만약, username과 age 뿐만 아니라 file까지 같이 담아 HTML Form을 서버에게 전송한다면?

>> Multipart/form-data를 사용한다.

이런 상황에서는 boundary라는 개념이 도입되어, 웹 브라우저가 자동으로 파트별로 내용을 자른다.

 

 

위 그림의 오른쪽 요청 메시지와 같이 username과 age, 그리고 file의 경계를 잘라서 HTTP 메시지에서 message body를 꾸려낸다.

 

HTML Form 데이터 전송을 다시 요약해보면

HTML Form submit할 때, POST 요청을 전송한다.
ex) 회원 가입, 상품 주문, 데이터 변경

Content-Type : applicant/x-www-form-urlencoded 사용
- form의 내용을 메시지 바디를 통해 전송(key=value 형식)
- 전송 데이터를 url encoding 처리
- ex) abc김 -> abc%EA%B9%80

HTML Form은 GET 전송도 가능하다.

Content-Type : multipart/form-data
- 파일 업로드 같은 바이너리 데이터 전송시 사용
- 다른 종류의 여러 파일과 폼의 내용 함께 전송 가능

HTML Form 전송은 GET, POST만 지원한다.

 

 

4. HTTP API 데이터 전송

 

4.1) HTTP API?

(HTTP API에 대해 감이 안 올 수 있어 간단히 설명)

 

HTTP API는 HTTP 프로토콜을 기반으로 동작하는 클라이언트와 서버 간의 데이터 교환을 가능하게 하는 프로그래밍 인터페이스이다. 서버와 클라이언트 간의 통신은 비단 웹 브라우저와 서버만을 말하는 게 아니라 앱- 서버 or 서버 - 서버 간의 통신이 될 수도 있다.

 

• 서버 to 서버 (백엔드 시스템간 통신) : 이때도 HTTP API가 사용될 것이다. 예를 들어, 주문 서버에서 결제 서버와 통신하게 되는 경우라고 생각하면 된다.
• App 클라이언트 : 아이폰이나 안드로이드 앱이 서버에 데이터를 요청하고 서버가 JSON 형식으로 응답을 보내는 방식이 될 수 있다.
• Web 클라이언트 : 웹 브라우저는 기본적으로 HTML과 같은 뷰 형식의 데이터를 응답으로 받기를 기대하겠지만, 그렇지 않은 JSON 데이터 형식을 받을 경우, 자바스크립트가 HTTP API를 호출하여 데이터를 주고 받게 된다.
  ex) React, Vue.js

 

4.2) HTTP 메서드와 HTTP API에서 데이터 전송

• POST, PUT, PATCH : 메시지 바디를 통해 데이터 전송한다.
  - POST : 새로운 데이터를 서버에 생성
  - PUT : 기존 데이터 수정
  - PATCH : 데이터 일부를 수정
• GET : 조회, 쿼리 파라미터로 데이터 전달

4.3) Content-Type

• Content-Type : 이 헤더는 전송되는 데이터의 형식을 나타낸다. 일반적으로 JSON 형식이 사용된다.
  >> application/json을 주로 사용하되, test/pain 혹은 application/xml이 쓰이기도 한다.

 

5. HTTP API 설계 예시

 

앞서 배운 내용을 기반으로 HTTP API를 설계해본다.

 

• HTTP API - 컬렉션
  - POST 기반 등록 ex) 회원 관리 API 제공
• HTTP API - 스토어
  - PUT 기반 등록 ex) 정적 컨텐츠 관리, 원격 파일 관리
• HTML Form 사용
  - GET, POST만 지원 ex) 웹 페이지 관리 

아래 과정을 통해 차례 차례 설계 방식을 알아보자.

 

5.1) HTTP API 컬렉션 설계 : POST 기반 등록

 

- 회원 목록 /members -> GET

- 회원 등록  /members -> POST

- 회원 조회 /members/{id} -> GET

- 회원 수정 /members/{id} -> PATCH, PUT, POST

- 회원 삭제 /members/{id} -> DELETE

 

POST와 PUT 기반으로 나눈 이유가 있으므로 일단 POST 기반 등록 설계 예시를 살펴보자.

 

< POST - 신규 자원 등록 특징>

• 클라이언트는 POST 메서드로 리소스를 생성하고자 할 때, 등록될 리소스의 URI를 모른다.
  (이전 게시글 POST 메서드 참고)
• 요청 메시지가 서버에게 전달되고 나면, 서버가 새로 등록된 리소스 URI를 생성한다.
  ex) HTTP/1.1 201 Created
        Location: /members/100 
• 컬렉션(Collection)
  - 서버가 관리하는 리소스 디렉토리를 의미한다.
  - 서버가 리소스 URI를 생성하고 관리한다.
  - 여기서 Collection은 /members이다.

5.2) HTTP API 스토어 설계 : PUT 기반 등록

 

- 파일 목록 /files-> GET

- 파일 등록  /files/{filename} -> PUT

- 파일 조회 /files/{filename} -> GET

- 파일 삭제 /files/{filename} -> DELETE

- 파일 대량 등록 /files -> POST

< PUT - 신규 자원 등록 특징 >  

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

(사실 PUT 기반 자원 등록은 잘 안 쓴다고 한다)

 

컬렉션, 스토어, 컨트롤러 등은 URI 설계 개념이니 추가로 공부하는 것이 좋겠다.

 

5.3) HTML FORM 사용

 

앞에서도 말했듯이 GET, POST만 지원한다.

 

- 회원 목록 /members -> GET

- 회원 등록 폼  /members/new -> GET

- 회원 등록 /members/new, /members -> POST

- 회원 조회 /members/{id} -> GET

- 회원 수정 폼 /memgers/{id}/edit -> GET

- 회원 수정 /members/{id}/edit, /members/{id} -> POST

- 회원 삭제 /members/{id}/delete -> POST

 

< HTML FORM 사용 > 

• 회원 삭제할 때 /members/{id}/delete -> POST로 써야 한다. 계속 강조하지만 HTML FORM 형식에서는 GET, POST 메서드만 지원하기 때문이다.
• 당연히 두 메서드만 쓰기엔 한계가 있다. 그래서 동사로 된 리소스 경로를 사용하게 된다.
  POST의 /new, /edit, /delete가 컨트롤 URI가 된다.
• HTTP 메서드로 해결이 애매한 경우 동사형 URI를 사용하면 된다. (HTTP API 포함)

 

 

[참고] : 인프런-김영한 <모든 개발자를 위한 HTTP 웹 기본 지식>