Self Question
1. 데이터 전달 방식
2. 정적,동적리소스,Form, HTTP API
3. API 설계 예시
4. 컬렉션과 스토어
5. 컨트롤 URI
6. 파일 등록

HTTP 메서드 활용

데이터 전달 방식

헤더를 이용한 요청

GET 메서드 사용 시 클라이언트의 요청 정보는 헤더에 담기고, 쿼리파라미터를 통해 데이터를 전송한다.

바디를 이용한 요청

POST, PUT, DELETE 메서드 사용 시 주로 HTTP메시지 바디를 통해 데이터를 전송한다.

클라이언트의 다양한 요청

정적 리소스 조회

이미지, 정적 테스트 문서, 순수 HTML 파일

쿼리 파라미터 미사용

단순 조회시

GET /mentors/mentor.jpg

정적 데이터는 일반적으로 쿼리 파라미터없이 리소스 경로로 단순하게 조회가 가능하다.

동적 리소스 조회

주로 검색, 게시판 목록에서 정렬 필터, JSP, Thymeleaf가 포함된 HTML

쿼리 파라미터 사용

GET /mentors?name=kim

쿼리 파라미터를 이용한 조회 방식은 주로 검색, 필터, 정렬에 사용된다.
클라이언트는 쿼리파라미터에 요청 데이터에대한 정보를 담고, 서버는 파라미터와 벨류값을 사용하여 응답 메시지를 작성한다.

HTML FORM을 통한 데이터 전송

회원가입, 로그인, 상품주문, 데이터 변경 등 폼을 통해 메시지 바디에 데이터를 담아 전송

메시지 바디

POST /mentors HTTP/1.1
Host: localhost:8080
Content-Type : application/x-www-from-urlencoded

name=kim&age=20

HTML Form은 주로 POST방식을 이용하는데, POST 메서드 사용 시 데이터는 HTTP 메시지 바디에 담겨 서버로 요청한다. 메시지 바디에 담긴 데이터는 쿼리 파라미터 형식이다.

GET /mentors?name=kim&age=20

HTML Form 사용 시 GET 요청도 가능하다. GET 요청시 요청데이터는 쿼리파라미터를 이용해 헤더에 담긴다.

<form entype="multipart/form-data">

폼 태그를 이용하여 파일을 업로드 할경우 인코딩 타입을 설정해 주어야한다.

HTTP API를 통한 데이터 전송

모든 요청이 가능하다. 서버 to 서버, 앱 클라이언트, 웹 클라이언트

POST /mentors HTTP/1.1
Content-Type:application/json
{
	"name":"kim",
    "age":20
}

주로 JSON형태를 사용하며, Content-Type:application/json을 설정 해주어야한다.

HTTP API 설계 예시

HTTP API - 컬렉션

POST 기반 등록, 클라이언트가 리소스에 대한 식별자를 모르는 상태에서 요청한다.
서버가 관리하는 리소스 디렉토리
서버가 리소스의 URI를 생성하고 관리한다.

HTTP API - 스토어

PUT 기반 등록, 클라이언트가 리소스에 대한 식별자를 알고있는 상태에서 요청한다.

HTML FORM사용

HTML Form은 아쉽게도 GET과 POST 메서드만 지원한다. 때문에, 개발 단계에서 다양한 메서드 이용시 주로, Postman을 설치하여 사용한다.

멘토링 서비스

멘토 목록 GET /mentors

멘토 등록 POST /mentors
: 바디에 멘토에 대한 정보를 담아서 보낸다.
클라이언트는 리소스 식별자를 모르는 상태에서 요청한다.(컬렉션)

멘토 조회 GET /mentors/{id}

멘토 수정 PATCH /mentors/{id}
: PATCH는 항목별로 각자 수정이 가능하기 때문에 수정 기능을 사용할 경우 PATCH를 사용하는것이 가장 좋다.

PUT : 그냥 완전 덮어 쓰기, 완전히 덮어써도 될때 사용한다.
그런데 실무에서는 상황 가능성이 없다. 주로 BoardContent 수정 시 사용된다.

멘토 삭제 DELETE /mentors/{id}

POST로 회원을 등록하면 서버가 신규 리소스에 대한 식별자 URI는 서버가 생성하는것이다.
그리고 응답메시지에 식별자를 담아서 클라이언트로 넘겨준다.

Location: /mentors/{식별자} 

클라이언트는 새로 등록되는 멤버에 대한 URI를 모른다.서버가 결정하여 클라이언트에게 제공한다.

위의 예시들을 사용 시
/mentors 가 컬렉션이 된다.

파일 관리 시스템

파일을 등록할때는 PUT을 사용한다.
기존 파일이 존재할때는 지우고 새로 올리고 없는 경우에도 파일을 온전히 올린다.
즉, PUT은 완전히 기존 리소스를 대체해 버린다.

PUT /files/{filename}

클라이언트가 직접 리소스의 URI를 지정한다.
PUT을 사용할 경우 클라이언트는 file에 대한 URI, 리소스를 알고 있어야한다.
그래야지만 정확한 위치, 리소스에 요청데이터를 온전히 덮어 쓸 수 있다.

스토어:
클라이언트가 관리하는 리소스 저장소. 클라이언트가 리소스의 URI를 알고 관리

위의 예시들을 사용 시
/files 가 스토어이다.

컬렉션과 스토어

POST: 컬렉션, 클라이언트가 리소스, URI를 모르며 서버가 관리한다.
PUT: 스토어, 클라이언트가 리소스, URI를 알고있으며 클라이언트가 관리한다.

멘토 등록 폼 URI 와 멘토 등록 URI를 일치시키는 것이 좋다. 불일치 할경우 새로고침하면 폼으로 다시 못돌아오고 다시 처음부터 시작해야한다.

멘토 등록 폼 : GET /mentors/new
멘토 등록   : POST /mentors/new

멘토 수정폼 URI = 멘토 수정 URI

멘토 수정 폼 : GET /mentors/{id}/edit
멘토 수정   : POST /mentros/{id}/edit

API 설계 시 URI는 주로 명사를 사용하고, 동사를 사용하지 않는다. 하지만, 명사로만 API 설계가 복잡하고, 힘든 경우에는 컨트롤 URI를 사용한다.

HTML Form: GET, POST만 지원하기 때문에 컨트롤 URI가 필요하다.
HTTP 메서드로 해결하기 애매한 경우 사용.(HTTP API포함)
이러한 제약을 해결하기 위해 동사로된 URI, 컨트롤URI를 사용
컨트롤 URI를 최대한 안쓰고 리소스만으로 절대 불가능할때 대체재로 사용하는것이다.

게시판, 파일을 올릴 경우에만 PUT을 사용하고 대부분 POST를 사용한다.

컬렉션,스토어,FORM 사용시 :
리소스만으로 URI를 설계하기가 정말 어렵다 싶으면 그러면 어쩔수 없이 컨트롤URI를 사용한다.

출처 : 김영한 (인프런)