HTTP 메서드로 API를 설계해보자.
- 서버로 데이터 전송
서버로 데이터를 전달하는 방식은 2가지이다.
쿼리 파라미터, 메시지 바디 두 가지이지만 사실 GET과 GET을 제외한 나머지이다.
- 쿼리 파라미터
GET
데이터를 조회할 때 사용
- 메시지 바디
POST, PUT, PATCH
회원 가입, 상품 주문, 리소스 등록
클라이언트에서 서버로 데이터를 전송하는 상황은 데이터를 조회하거나, HTML form을 통한 데이터 전송, HTTP API를 통한 데이터 전송할 때이다.
차례로 살펴보자.
- 정적 데이터 조회
어차피 정적이기 때문에 쿼리 파라미터를 사용하지 않는다.
- 동적 데이터 조회
정적 데이터 조회와는 다르게 쿼리 파라미터를 사용하여 동적으로 결과를 받아온다.
- HTML form을 이용하여 데이터 전송
우선 HTML Form 전송은 GET, POST만 지원을 한다.
그러니 조회를 제외한 대부분은 POST를 사용한다.
POST 방식으로 파일도 전송이 가능하다.
이렇게 다른 종류의 여러 파일과 폼의 내용을 함께 전송하려면 Content-Type: multipart/form-data를 사용한다.
-HTTP API 데이터 전송
보통 이렇게 API 데이터만 전송하는 경우는 서버 to 서버로 사람이 보지 않을 때이다.
Content-type: application/json이 사실상 표준이 되었다.
- HTTP API 설계
우선 등록을 POST로 하는 POST 기반 등록부터 알아보자.
POST 기반 등록
- 학생 목록 /students -> GET
- 학생 등록 /students -> POST
- 학생 조회 /students/{id} -> GET
- 학생 수정 /students/{id} -> PATCH, PUT, POST
- 학생 삭제 /students/{id} -> DELETE
클라이언트는 등록될 리소스의 URI를 모르기 때문에 서버가 새로운 리소스 URI를 생성해준다.
그리고 이렇게 만든 리소스를 관리하는 디렉토리를 컬렉션이라고 한다.
PUT 기반 등록
- 파일 목록 /files -> GET
- 파일 조회 /files/{filename} -> GET
- 파일 등록 /files/{filename} -> PUT
- 파일 삭제 /files/{filename} -> DELETE
- 파일 ??? /files -> POST
POST 기반 등록과는 다르게 클라이언트가 리소스의 URI를 알고 있어야 한다.
클라이언트가 직접 리소스의 URI를 지정하기 때문에 클라이언트가 리소스를 관리하고 그 저장소를 스토어라고 한다.
HTML FORM 사용
- 학생 목록 /students -> GET
- 학생 목록 폼 /students/new -> GET
- 학생 등록 /students/new -> POST
- 학생 조회 /students/{id} -> GET
- 학생 수정 폼 /students/{id}/edit -> GET
- 학생 수정 /students/{id}/edit -> POST
- 학생 삭제 /students/{id}/delete -> POST
HTML FORM은 GET, POST만 지원한다.
그렇기 때문에 어쩔 수 없이 동사로 된 리소스 경로를 사용한다.
HTTP 메서드로도 어쩔 수 없는 경우에만 사용한다.