대바보의 끄적끄적

클라이언트에 서버로 데이터 전송

주로 GET에선 쿼리 파라미터로 전송한다.

body도 되긴 하나 잘 사용하지 않는다.

POST, PUT, PATCH에선 HTTP 메시지 body로 보낸다.

정적 데이터 조회

- GET을 사용한다.

- 쿼리 파라미터를 사용하지 않는다.

- 이미지를 가져올 때 사용한다.

동적 데이터 조회

- GET을 사용한다.

- 쿼리 파라미터를 기반으로 결과를 동적으로 생성

- 검색어 = 필터 라한다.

HTML FORM 전송

- POST를 사용한다.

- 웹 브라우저가 FORM데이터를 읽어 HTTP 메시지를 생성해준다.

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

- HTTP 메시지 바디에 담아 서버로 보낸다.

- GET으로 변경도 가능하나 데이터 변경 작업이 있으면 사용하면 안 된다.(조회에서 사용 가능)

HTML FORM 데이터 전송

- multipart/form-data

- form에 파일을 담아 보낼 때 사용한다.

- 파일만 가는 게 아니라 form데이터 전체를 보낸다.

- Content-Type: multipart/form-data;boundary=123

- 바운더리로 구분한다.

HTTP API 전송

- 서버 TO 서버

- 앱 클라이언트

- 웹 클라이언트(ajax, React, Vue)

- GET, POST, PUT, PATCH 다 사용 가능하다.

- Content-Type : application/json을 주로 사용한다.

HTTP API 설계 예시

리소스 기반(/members)으로 설계한다.

[

회원 목록 /members -> GET

회원 등록 /members -> POST

회원 조회 /members/{id} -> GET

회원 수정 /members/{id} -> PATCH, PUT, POST

회원 삭제 /members/{id} -> DELETE

]

HTTP API - 컬렉션

(서버가 관리하는 리소스 디렉터리)

- POST 기반 등록

POST로 등록할 시 등록될 URI정보를 모른다.

서버에서 RESPONSE에 Location을 담아준다.

즉, 서버에 요청해 서버가 정해준다.

HTTP API - 스토어

(클라이언트가 관리하는 리소스 저장소)

- PUT 기반 등록

클라이언트가 직접 리소소의 URI를 지정한다.

클라이언트에서 서버에 원격으로 데이터를 넣을 때 사용한다.

클라이언트가 파일 이름을 알고 있고 파일을 업로드할 때 사용한다.

POST, PUT 중에선 주로 POST를 사용한다.

HTTP FORM 사용

GET, POST만 지원한다.

컨트롤 URI를 사용한다. ex) /members/{id}/delete

FORM은 GET,POST만 지원해 제약이 있다.

제약을 해결하기 위해 동사로 된 리소스 경로를 사용한다.

/members/{id}/delete

좋은 URI 설계 개념

문서

- 단일 개념(파일 하나, 객체 하나)

-/members/100

컬렉션

- 서버가 관리하는 리소스 디렉터리

- 서버가 리소스의 URI를 생성하고 관리

스토어

- 클라이언트가 관리하는 자원 저장소

- 클라이언트가 리소스의 URI를 알고 관리

컨트롤러, 컨트롤 URI

- 문서, 컬렉션, 스토러로 해결하기 어려운 추가 프로세스 실행

- GET, POST, PUT, PATCH만으로.

- /members/{id}/delete