HTTP API의 종류
URI에서 중요한 것은 리소스이며, 행위(작업)는 method 로 따로 기입한다.
리소스란 조회, 수정, 삭제 등의 행위가 아닌, 그 작업의 대상이 되는 것을 말한다.
GET : 리소스를 조회할때 사용
POST : 요청 데이터를 서버에서 처리. 주로 새로운 데이터를 등록할때 사용.
PUT : 기존 리소스를 대체. 해당 리소스가 없다면 새롭게 생성
PATCH : 리소스 부분 변경. 주로 수정에 사용.
DELETE : 리소스 삭제
이외에 기타 메서드로 HEAD, OPTIONS 등이 존재한다.
1. GET
서버에 전달하고 싶은 데이터는 query를 통해 전달한다. 최근 들어 스펙상으로 메시지 바디를 통해 전달할수 있지만, 지원하지 않는 서버가 많기에 권장하지 않는다.
2. POST
요청 데이터를 서버에서 처리한다. 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행하며 주로 신규 데이터 등록, 프로세스 처리에 사용된다.
단순히 새로운 데이터를 등록할때만 사용하는 것이 아니라 물건 주문 -> 결제 -> 배달 -> 배달 완료처럼 단순한 값 변경을 넘어 프로세스가 변경되는 경우에도 POST방식으로 처리할수 있으며, 기존 문서의 끝에 새로운 내용이 추가되는 경우처럼 새로운 리소스가 생기지 않을수도 있다.
다른 메서드로 처리하기 애매한 경우( ex : JSON으로 조회 데이터를 넘겨야하는데 GET를 사용하기 어려운 경우)에도 POST방식을 사용할수 있다.
3. PUT
기존 리소스를 대체한다. 기존에 있는 데이터를 전부 삭제 후 새로 입력된 데이터로 바뀌며, 만약 기존 데이터가 없다면 새롭게 입력된다. 수정이 아닌 삭제 후 입력이기 때문에 잘못 사용하면 리소스가 날아갈 위험이 존재한다.
PUT을 사용하기 위해서는 클라이언트가 리소스를 식별해야 한다. 즉, 클라이언트가 리소스의 위치를 알고 있고 이를
/member/1001
처럼 uri에 명확히 지정해줘야 한다.
4. PATCH
리소스를 일부 변경(수정) 한다. 서버에서 지원하지 않을 경우 POST로 대체 가능하다.
5. DELETE
리소스를 삭제한다.
HTTP 메서드의 속성
HTTP 메서드는 3개의 속성을 지닌다.
1. 안전(safety)
해당 메서드로 호출하더라도 리소스를 변경하지 않는다. 소프트웨어 내부의 오류는 고려하지 않는다.
해당하는 method : GET
2. 멱등(idempotent)
몇번이고 실행해도 결과가 항상 똑같다. 즉, 첫번째 요청과 두번째 요청 모두 결과가 똑같은 것을 말한다. 서버가 요청에 응답해주지 못했을 경우, 서버가 재요청을 하더라도 문제가 없는지 판단하는 근거가 된다.
put은 전체 데이터를 삭제 -> 신규 데이터로 등록 메커니즘이므로 사용자의 요청이 같다면 100번을 요청해도 같은 결과로 나온다. PATCH도 마찬가지이며, DELETE도 특정 리소스가 삭제된 데이터가 출력된다.
그러나 POST의 경우 100번 요청하면 새로운 데이터가 100개가 더 생길수 있기에 결과가 달라진다.
PATCH역시 멱등이 아닌데, 예를 들어 기존의 숫자 데이터에 무조건 +10을 수정한다는 식으로 설계가 가능하기 때문이다.
해당하는 method : GET, PUT, DELETE
3. 캐시가능(Cashable)
응답 결과 리소스를 캐시해서 사용가능함을 의미한다.
GET, HEAD, POST, PATCH 가 해당하나, POST, PATCH는 본문 내용까지 캐시 키로 고려해야하는데 구현이 어려우 잘 사용되지 않는다.
해당하는 method : GET, HEAD, POST, PATCH
HTTP 설계
크게 POST 기반 등록과 PUT기반 등록, HTML form 사용하는 세가지 방식이 존재한다(HTML form 은 get/post만 사용가능하기에 보통은 AJAX를 사용한다).
(1) POST 기반 - 컬렉션(Collection)
POST는 리소스가 등록될 경로(URI, 식별자) 를 클라이언트가 지정해주지 않아도 된다. 새롭게 등록될 리소스 경로는 서버가 생성해준다. 대부분 이를 사용한다.
예를 들어 신규 회원이 가입될때 /member/{memberNum} 처럼 직접 리소스 경로를 지정해주지 않고 /member 처럼 뒤의 /{memberNum}을 제외하고 신규 등록이 가능하다. 여기서 member 는 컬렉션이 된다.
(2) PUT 기반 - 스토어(Store)
PUT은 리소스가 등록될 경로(URI, 식별자) 를 클라이어트가 지정해줘야 한다. 즉, 클라이언트가 직접 URI를 관리한다고 볼수 있다.
거의 사용되지 않지만 파일 관리와 같은 일에는 사용 가능하다.
/file/{fileName} 과 같이 직접 리소스 경로를 지정해줘야 한다. 이때 /files 를 스토어라고 한다.
이를 사용할 경우 POST의 의미를 사용자가 가 임의로 정할수 있다.
(3) HTML form 기반 - 컨트롤 URI
GET / POST 만 지원하기에 일반적으로 AJAX를 사용한다.
POST 요청을 form으로 전송할시, 브라우저가 알아서 content-type를 application/x-www-form-urlencoded 로 지정한다. 이후 키-벨류 형태로 HTTP 바디에 삽입한다.
GET 요청을 form으로 전송할시, 브라우저가 알아서 query로 만든다.
enctype 옵션을 직접 지정해서 컨텐츠 인코딩 타입을 지정해줄수 있는데, 기본은 application/x-www-form-urlencoded 이다. 직접 multipart/form-data 로 지정해줄수 있는데, 전송하려는 데이터에 byte로 이뤄진 이미지 등의 데이터가 존재할때 웹 브라우저가 데이터를 개별적으로 분석해서 맞는 컨텐츠 타입을 지정해준다.
글자는 application/x-www-form-urlencoded로, 이미지는 image/png로 컨텐츠 타입을 지정해준다.
메서드가 부족하다는 제약을 해결하기 위해 동사로 된 리소스를 사용할 수 있다.
ex)
수정 : member/edit
삭제 : member/delete 등등...
이때 동사로 이뤄진 /edit, /delete 가 컨트롤 URI가 된다.
URI 설계에 참조할만한 개념
문서(document)
- 단일 개념(파일 하나, 객체 인스턴스, DB의 row)
컬렉션
- 서버가 관리하는 리소스 디렉토리
- 서버가 리소스 URI 를 생성하고 관리한다.
스토어
- 클라이언트가 관리하는 자원 저장소
- 클라이언트가 리소스 URI를 알고 관리한다.
컨트롤러, 컨트롤 URI
- 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행에 사용
- 동사를 직접 사용 가능하다.
'공부 > 네트워크' 카테고리의 다른 글
| HTTP 헤더와 캐시 (2) | 2023.09.07 |
|---|---|
| URI와 HTTP의 기본 (0) | 2023.09.01 |
| 1. 인터넷 네트워크 (0) | 2023.08.25 |