Content-Type : application/x-www-form-urlencoded 사용
form의 내용을 메시지 바디를 통해서 전송
전송 데이터를 url encoding 처리
GET전송도 가능 (쿼리 파라미터로 데이터 전달)
Content-Type: multipart/form-data
파일 업로드같은 바이너리 데이터 전송시 사용
다른종류의 여러 파일과 폼의 내용 함께 전송 가능
HTML form 전송은 GET,POST만 지원
HTTP API를 통한 데이터 전송
서버 to 서버
앱 클라이언트
웹 클라이언트
POST, PUT, PATCH : 메세지 바디를 통해 데이터 전송
GET : 조회, 쿼리 파라미터로 데이터 전달
Content-Type: application/json을 주로 사용 (사실상 표준)
API 설계
POST 기반 등록 (많이사용)
클라이언트는 등록될 리소스의 URI를 모른다.
서버가 새로 등록된 리소스 URI를 생성해준다.
컬렉션(Collection)
서버가 관리하는 리소스 디렉토리
서버가 리소스의 URI를 생성하고 관리
ex) /members
PUT 기반 등록
클라이언트가 리소스 URI를 알고 있어야 한다.
클라이언트가 직접 리소스의 URI를 지정한다.
스토어(Store)
클라이언트가 관리하는 리소스 저장소
클라이언트가 리소스의 URI를 알고 관리
ex) /files
HTML FORM 사용
HTML FORM은 GET, POST만 지원
PUT, DELETE를 사용할 수 없으므로 동사로 된 리소스 경로를 사용한다.
이를컨트롤 URI라고 부른다
ex) /new, /edit, /delete 경로를 POST로 보냄
HTTP 메서드로 해결하기 애매한 경우 사용
참고하면 좋은 URI 설계 개념
• 문서(document) • 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row) • 예) /members/100, /files/star.jpg • 컬렉션(collection) • 서버가 관리하는 리소스 디렉터리 • 서버가 리소스의 URI를 생성하고 관리 • 예) /members • 스토어(store) • 클라이언트가 관리하는 자원 저장소 • 클라이언트가 리소스의 URI를 알고 관리 • 예) /files • 컨트롤러(controller), 컨트롤 URI • 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행 • 동사를 직접 사용 • 예) /members/{id}/delete
