HTTP 헤더
header-field = field-name":" field-value
HTTP 전송에 필요한 모든 부가정보
메세지 바디의 내용, 메세지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보...
표준 헤더가 너무 많음
HTTP 바디
실제 전송할 데이터
HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능
HTTP API 설계
회원 목록 조회 /read-member-list(x)
회원 조회 /read-member-by-id(x)
회원 등록 /create-member(x)
회원 수정 /update-member(x)
회원 삭제 /delete-member(x)
가장 중요한 건 리소스 식별
회원이라는 개념 자체가 바로 리소스
회원이라는 리소스만 식별하면 된다
회원 목록 조회 /members
회원 조회 /members/{id}
회원 등록 /members/{id}
회원 수정 /members/{id}
회원 삭제 /members/{id}
(참고로 계층 구조상 상위를 컬렉션으로 보고 복수단어 사용 권장)
리소스와 행위를 분리해서 행위를 HTTP 메서드로 표현(GET,POST,PUT,DELETE)
HTTP METHOD
GET: 리소스 조회
POST: 요청 데이터 처리, 주로 등록에 사용
PUT: 리소스를 대체, 해당 리소스가 없으면 생성
PATCH: 리소스 부분 변경
DELETE: 리소스 삭제
GET
리소스 조회
서버에 전달하고 싶은 데이터는 query를 통해서 전달
메세지 바디를 사용해서 데이터를 전달할 수 있지만 지원하지 않는 곳이 많아서 권장하지 않음
POST
요청 데이터 처리
메세지 바디를 통해 서버로 요청 데이터 전달
주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
새 리소스 등록
컨트롤 URI도 필요할 수 있음
다른 메서드로 처리하기 애매한 경우
PUT
리소스를 대체
- 리소스가 있으면 대체, 없으면 생성(덮어씌우기)
클라이언트가 리소스를 식별(POST는 서버가 식별)
PATCH
리소스 부분 변경
DELETE
리소스 제거
HTTP 메서드의 속성
안전
- 호출해도 리소스를 변경하지 않는다(안전은 리소스에 대해서만 고려)
멱등
- 한번 호출하든 두번 호출하든 100번 호출하든 결과 같다(POST 제외)
캐시가능
- GET, HEAD, POST, PATCH 캐시 가능
HTTP 메서드 활용
데이터 전달방식은 크게 2가지로 쿼리 파라미터를 통하거나 바디를 통하거나
클라이언트에서 서버로 데이터 전송
- 정적 데이터 조회
- 이미지, 정적 텍스트 문서
- 동적 데이터 조회
- 검색, 게시판 필터링, 검색어
- HTML Form을 통한 데이터 전송
- 회원가입, 상품주문, 데이터변경
- HTTP API를 통한 데이터 전송
- 서버 to 서버, 앱 클라이언트, 웹 클라이언트(Ajax)
- 회원가입, 상품주문, 데이터변경
1. 정적 데이터 조회
이미지 정적 텍스트 문서
조회는 GET 사용
정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회가능
2. 동적 데이터 조회
주로 검색, 게시판 목록에서 정렬 필터(검색어)
조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용
조회는 GET 사용
GET은 쿼리 파라미터 사용해서 데이터를 전달
3. HTML Form 데이터 전송
HTML Form submit 시 POST 전송
- 회원가입, 상품주문, 데이터 변경
Content-Type: application/x-www-form-urlencoded 사용
- form의 내용을 바디에 담아 전송(key,value 형식)
- 전송 데이터를 url encoding 처리
- abc 김-> abc%EA%B9%80
Content-Type: multipart/form-data
- 파일 업로드 같은 바이너리 데이터 전송시 사용
- 다른 종류의 여러 파일과 폼의 내용 함께 전송 가능
- 참고로 HTML Form 전송은 GET, POST만 지원
- 그래서 한계가 있어 동사로 된 리소스 경로 사용(/new, /edit, /delete 등 컨트롤 URI)
4. HTTP API 데이터 전송
서버 to 서버
앱 클라이언트 , 웹클라이언트
POST, PUT, PATCH: 메세지 바디를 통해 데이터 전송
GET: 조회, 쿼리 파라미터로 데이터 전달
Content-Type: application/json을 주로 사용(사실상 표준)
참고하면 좋은 URI 설계 개념
문서(document)
- 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)
- /members/100, /files/star.jpg
컬렉션(collection)
- 서버가 관리하는 리소스 디렉터리
- 서버가 리소스의 URI를 생성하고 관리
- /members
스토어(store)
- 클라이언트가 관리하는 자원 저장소
- 클라이언트가 리소스의 URI를 알고 관리
- /files
컨트롤러(controller), 컨트롤 URI
- 문서 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
- 동사를 직접 사용
- /members/{id}/delete
