📘클라이언트에서 서버로 데이터 전송
- 쿼리 파라미터를 통한 데이터 전송
- GET
- 주로 정렬 필터(검색어) EX) q=hello
- 메시지 바디를 통한 데이터 전송
- POST,PUT,PATCH
- 회원가입, 상품주문, 리소스 등록, 리소스 변경
4가지 상황
- 정적 데이터 조회
- 이미지, 정적 텍스트 문서등, GET을 통해 사용하며 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능.
- 동적 데이터 조회
- 주로 검색, 게시판 목록에서 정렬 필터(검색어)
- 조회 조건을 줄여주는 필터, 정렬등에 주로 사용한다.
- 조회는 GET사용하며, 이때는 쿼리 파라미터를 사용해서 데이터를 전달한다.
- HTML FORM 데이터 전송
- POST 전송
HTML 폼안에 키,값을 통해서 데이터 전송 서버에서 메시지 바디에 키값을 넣어준다.
- GET 전송
키,값을 URL경로에 쿼리로 넣는다.
-> GET은 조회에서만 사용하자
- enctyep = "multipart/form-data" 주로 binary데이터 전송할 때사용
content type이 여러 type일때, string, 파일등을 같이 보내야 할때 사용
웹 브라우저에서 여러 part로 나눠서 분류해준다.
- HTTP API 데이터 전송
- 서버와 서버, 앱 클라이언트, 웹 클라이언트(AJAX)에서 주로 사용한다.
- 메시지 바디를 통해 데이터 전송, GET은 조회, 쿼리 파라미터로 전달
- Content-type: application/json을 주로 사용한다.
📘HTTP API 설계 예시
POST 기반 등록
- 메시지에 데이터 정보를 넣어서 서버에 전달한다.
- 서버에서는 리소스를 DB에 저장하고 리소스 식별자(URI)를 생성한다.
- 응답 데이터에 Location에 리소스 식별자(URI)를 포함하여 넘겨준다.
-> POST 기반 등록에서는 리소스 식별자(URI)를 서버가 생성한다.
이러한 방식을 컬렉션이라고 부른다.
PUT 기반 등록
-> PUT 기반 등록에서는 클라이언트가 리소스 URI를 알고 넣어서 데이터를 전송해야한다.
이러한 방식을 스토어라고 부른다
- GET, POST만 지원한다.
- 컨트롤 URI
GET,POST만 지원하는 제약을 해결하기 위해 동사로된 리소스 경로 사용
EX) /edit, /delete
📗URI 설계 개념
문서
컬렉션
스토어
컨트롤러, 컨트롤 URI
- 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
- 동사를 직접 사용