5. HTTP 메서드 활용

전달 방식

데이터 전달 방식은 크게 2가지이다.

 

1. 쿼리 파라미터를 통한 데이터 전송

• GET
• 주로 검색어를 넣거나 정렬 조건을 넣을 때 사용한다.

 

2. 메시지 바디를 통한 데이터 전송

• POST, PUT, PATCH
• 회원 가입, 주문, 리소스 등록, 리소스 변경에 사용한다.

 

클라이언트에서 서버로 데이터 전송하는 상황에는 4가지가 있다.

1. 정적 데이터 조회
2. 동적 데이터 조회
3. HTML Form을 통한 데이터 전송
4. HTTP API를 통한 데이터 전송

 

1. 정적 데이터 조회 - 쿼리 파라미터 미사용

• 이미지, 정적 텍스트 문서 전달
• GET 사용
• 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능

클라이언트에서 “별” 이미지를 보내면 추가 데이터가 필요없다. URI 경로만 넣으면 된다.

쿼리 파라미터로 추가적인 데이터 전달 없이 경로만 넣으면 이미지 리소스를 만들어서 보내준다.

 

2. 동적 데이터 조회 - 쿼리 파라미터 사용

“?q=hello&hI=ko” 이 부분이 쿼리 파라미터 부분

• 주로 검색, 게시판 목록 정렬 필터에서 사용한다. - 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 사용한다.
• 조회는 GET을 사용하며, GET은 쿼리 파라미터를 사용해서 데이터 전달한다.

 

경로에 검색어나 추가 조건을 쿼리 파라미터에 넣어 보내고, 서버는 쿼리 파라미터를 key=value 로 꺼내서 결과를 만들어 보낸다.

 

3. HTML Form 데이터 전송

 

1)POST전송 - 저장

form submit(전송) 버튼을 누르면 폼의 데이터를 읽어서 오른쪽 HTTP 메시지를 생성해준다.

Content-Type: application/x-www-form-urlencoded

username=Kim&age=20

쿼리 파라미터처럼 생긴 모습으로 http body에 넣는다.

지금까지는 GET의 url로 치는것만 했는데, html form 태그로 넣을 수도 있다.

 

2)GET전송-저장

만약 GET으로 바꿔서 폼 데이터를 전송한다면, GET은 message body를 안쓰니까, 웹 브라우저는 HTTP 메시지를 GET처럼 쿼리 파라미터로 만든다.

POST면 message body에 넣고, GET이면 URL 경로에 넣는다.

하지만 GET은 조회에만 사용하므로 절대 이렇게 사용하면 안된다. 조회용으로 사용한다면 괜찮다.

 

3)파일 전송 - multipart/form-data

Content-Type의 기본값은 application/x-www-form-urlencoded-multipart/form-data로 하면 byte로 되어있는 바이너리 파일을 같이 보낼 수 있다. 그럼 boundary가 자동으로 경계를 잘라준다.

 

정리

• HTML FORM submit시 POST 전송의 경우

ex) 회원 가입, 상품 주문, 데이터 변경

 

• Content-Type: application/x-www-form-urlencoded  사용

form의 내용을 메시지 바디를 통해서 전송(key=value, 쿼리 파라미터 형식)

전송 데이터를 url encoding 처리, ex) abc김 -> abc%EA%B9%80

 

• HTML FORM은 GET 전송도 가능하다. (쿼리 파라미터 형식으로)
• Content-Type: multipart/form-data

파일 업로드 같은 바이너리 데이터 전송시 사용한다.

다른 종류의 여러 파일과 폼의 내용 함께 전송 가능하다.(그래서 이름이 multipart)

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

 

4. HTTP API 데이터 전송

정리하자면

• 서버끼리 서로 통신할 때 사용한다. - html 같은 것이 전혀 없으므로 데이터만 전송한다.
• 앱 클라이언트에서 데이터를 전송할 때 사용한다.
• 웹 클라이언트와 통신할 때 사용한다.
     - 1) html의 form 전송 대신, 자바 스크립트를 통해 전송 = AJAX 통신 
     - 2) react, vue 같은 웹 클라이언트와 API 통신
• POST, PUT, PATCH 사용 시: 메시지 바디로 데이터 전송
• GET 사용 시: 조회,쿼리 파라미터로 데이터 전달 (메시지 바디 포함할 수는 있지만 실질적으로 사용 안한다.)
• Content-Type:application/json을 주로 사용한다. 표준TEXT, XML, JSON이 있는데 현재는 JSON이 대부분 사용된다.

 

HTTP API 설계 예시

 

(1) HTTP API - 컬렉션

POST 기반 등록 ex) 회원 관리 API

(2) HTTP API - 스토어

PUT 기반 등록 ex) 정적 컨텐츠 관리, 원격 파일 관리리

(3) HTML FORM

웹 페이지 회원 관리, GET, POST만 지원

 

(1) HTTP API 컬렉션

ex) 회원 관리 시스템을 POST 기반으로 등록해보자

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

API는 리소스만 관리해야 하고, 어떻게 할지는 HTTP 메서드로 알려준다.

수정에서 PUT은 완전히 덮어쓰는 기능이므로 부분 업데이트를 하는 PATCH를 쓰는 게 가장 좋다.

게시글을 수정하는 경우라면 완전히 덮어쓸 수 있으므로 PUT을 사용할 수 있고,

이것도 저것도 애매하다면 POST를 사용한다.

 

POST로 신규 자원 등록

• 클라이언트는 등록될 리소스의 URI를 모른다.
• 서버가 새로 등록된 리소스 URI를 생성해준다.

Location: /members/100

100 이라는 식별자가 서버에서 만들어진다.

• 컬렉션

서버가 관리하는 리소스 디렉토리로, 서버가 리소스의 URI를 생성하고 관리하며 여기서 컬렉션은  /members 를 의미한다.

 

(2) HTTP API 스토어

PUT으로 신규 자원 등록

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

파일을 새로 업로드 할 때는 PUT이 적합하다. 기존 파일이 있으면 지우고 다시 올려야 하기 때문이다.

PUT을 자원 등록으로 사용하고 있기 때문에 POST를 임의로 정할 수 있다.

• 클라이언트가 리소스 URI를 알고 있어야 한다.

files/{filename} → filename 이라는 식별자를 클라이언트가 알고 있어야 한다.

• 클라이언트가 직접 리소스의 URI를 지정하고 관리한다.

POST로 생성할 때는 데이터만 넘기면 서버가 알아서 만들어 내려준다.

• 스토어

클라이언트가 관리하는 리소스 저장소로 클라이언트가 리소스의 URI를 알고 관리하며 여기서 스토어는 /files 를 의미한다.

대부분 POST로 생성하며, 파일과 같은 특수한 경우에만 PUT을 사용한다.

 

(3)HTML FORM 사용

순수한 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

같은 URI를 사용하면서 메서드만 다르게 하는 것을 선호한다.

/members 보다는 /members/new 를 선호한다는 것

데이터에 문제가 있어서 서버에 보낸 값을 다시 폼에 던져야할 때가 있다. 이때 URI가 통일되어 있으면 경로를 수정하지 않고도 깔끔하게 해결할 수 있다.

수정 폼도 실제 수정하는 게 아니라 폼을 불러오기만 할 뿐이므로 GET을 사용한다.

 

(+) 컨트롤 URI

HTML FORM은 delete를 쓰지 못하므로 삭제할 때는 어쩔 수 없이 /delete 를 붙여서 컨트롤 URI라는 형태로 사용해야 한다.

• GET, POST만 지원하므로 제약이 있다.
• 이런 제약을 해결하기 위해 동사로 된 리소스 경로를 사용한다.
• POST의 /new, /edit, /delete 가 컨트롤 URI가 된다.
• HTTP 메서드로 해결하기 애매한 경우 사용하며 최대한 리소스 개념을 가지고 설계하고, 정말 안될때만 사용한다.

 

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

문서(document)

단일 개념: 파일 하나, 객체 인스턴스, 데이터베이스 row 등 ex) /members/100, /files/star.jpg

컬렉션(collection)

서버가 관리하는 리소스 디렉토리로 서버가 리소스의 URI를 생성하고 관리 ex) /members

스토어(store)

클라이언트가 관리하는 자원 저장소로 클라이언트가 리소스의 URI를 알고 관리 ex) /files

컨트롤러(controller) (= 컨트롤 URI)

문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행하며 동사를 직접 사용 ex) /members/{id}/delete

정리하자면

회원 컬렉션이므로 /members, 주문이면 /orders

상세정보는 /orders안에 주문번호로 표현한다.

이것만으로도 안되면 컨트롤 URI 사용한다.

즉, 문서와 컬렉션으로 최대한 해결하고, 안되면 컨트롤 URI로 해결