[HTTP 웹 지식] HTTP 메서드, 메서드 활용

인프런 김영한님의 모든 개발자를 위한 HTTP 웹 지식 강의를 듣고 정리했습니다.

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

 

 

 

HTTP API를 만들어보자

 

 

URI 설계

 

회원 목록 조회 /read-memeber-list

회원 조회 /read-member-by-id

회원 등록 /create-member

회원 수정 /update-member

회원 삭제 /delete-member

 

이것이 좋은 URI 설계인가? => 가장 중요한 것은 리소스 식별

 

리소스 : 회원

 

회원을 등록하고 수정하고 삭제하는 것을 모두 배제하고 회원이라는 리소스만 식별하면 된다 => 회원 리소스를 URI에 매핑

 

리소스 식별, URI 계층 구조 활용

 

회원 목록 조회 /members

회원 조회 /members/{id} -> 어떻게 구분하지?

회원 등록 /members/{id}

회원 수정 /members/{id}

회원 삭제 /members/{id}

 

리소스와 행위를 분리 => 가장 중요한 것은 리소스를 식별하는 것

 

URI는 리소스만 식별

리소스 : 회원

행위 : 조회, 등록, 삭제, 수정

 

 

 

HTTP 메서드 = GET, POST

 

 

주요 메서드

 

GET : 리소스 조회

POST : 요청 데이터 처리, 주로 등록에 사용

PUT : 리소스를 대체, 해당 리소스가 없으면 사용

PATCH : 리소스 부분 변경

DELETE : 리소스 삭제

 

기타 메서드

 

HEAD : GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환

OPTIONS : 대상 리소스에 대한 통신 가능 옵션을 주로 설명

CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정

TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

 

 

GET

- 리소스 조회

- 서버에 전달하고 싶은 데이터는 query를 통해서 전달한다.

- 메시지 바디를 사용해서 데이터를 전달할 수 있지만 지원하지 않는 곳에 많아 권장하지 않는다. 

 

POST

- 요청 데이터 처리

- 메시지 바디를 통해 서버로 요청 데이터를 전달한다.

- 서버는 요청 데이터를 처리한다.

- 주로 신규 리소스 등록, 프로세스 처리에 사용한다. 

 

POST는 어떻게 요청 데이터를 처리할까?

: 대상 리소스가 리소스 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청한다. 

ex) HTML FORM 에 입력한 정보로 회원 가입, 주문 등에서 사용, 게시판 글쓰기, 댓글 달기, 신규 주문 생성, 한 문서 끝에 내용 추가하기

 

POST 특징

 

1. 새 리소스 생성

- 서버가 아직 식별하지 않은 새 리소스 생성

 

2. 요청 데이터 처리

- 단순히 데이터를 생성하거나, 변경하는 것을 넘어 프로세스를 처리해야하는 경우

주문 -> 결제 완료 -> 배달 시작 -> 배달 완료 와 같은 프로세스의 상태 

 

3. 다른 메서드로 처리하기 애매한 경우

- 애매하면 POST

 

 

 

HTTP 메서드 - PUT, PATCH, DELETE

 

 

PUT
- 리소스를 완전히 대체 (리소스 있으면 대체, 없으면 생성)

- 클라이언트가 리소스를 식별 (클라이언트가 리소스 위치를 알고 URI 지정한다)

 

 

PATCH

- 리소스 부분 변경

 

DELETE

- 리소스 제거

 

 

 

HTTP 메서드의 속성

 

 

안전 (safe)

호출해도 리소스를 변경하지 않는다. GET, HEAD, OPTIONS, TRACE 외에는 안전하지 않다.

 

계속 호출해서 로그가 쌓여서 장애가 발생하면? => 안전은 해당 리소스만 고려하지 이 부분은 고려하지 않는다. 

 

멱등 (idempotent)

한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다. 

GET, PUT, DELETE는 멱등이다.

POST는 멱등이 아니다. 두 번 호출시에 같은 결제가 중복해서 발생할 수 있다. 

활용

- 자동 복구 메커니즘

 

재요청 중간에 다른 곳에서 리소스를 변경하면? => 멱등은 외부 요인으로 중간에 리소스가 변경되는 것을 고려하지 않는다. 

 

 

캐시가능 (cacheable)

응답 결과 리소스를 캐시해서 사용해도 되는가?

GET, HEAD, POST, PATCH 가능

실제로는 GET, HEAD 정도만 사용한다. 

 

 

 

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

 

 

데이터 전달 방식 2가지

 

1. 쿼리 파라미터를 통한 데이터 전송

- GET

- 주로 정렬 필터 (검색어)

 

2. 메시지 바디를 통한 전송

- POST, PUT, PATCH

-회원 가입, 상품 주문, 리소스 등록, 리소스 변경

 

 

클라이언트에서 서버로 데이터 전송 시 4가지 상황

 

1. 정적 데이터 조회

2. 동적 데이터 조회

3. HTML FROM을 통한 데이터 전송

4. HTTP API를 통한 데이터 전송

 

 

정적 데이터 조회

쿼리가 필요없다. 

이미지, 정적 텍스트 문서이며 GET 메서드를 사용한다. 

동적 데이터 조회

주로 검색, 게시판 목록에서 정렬 필터로 사용된다.

GET 메서드를 사용한다. (쿼리 파라미터 사용)

HTML FROM 데이터 전송

POST 전송 - 저장

form에서 전송 버튼을 누르면 웹 브라우저가 요청 HTTP 메시지를 생성한다. 

form에서 get메서드로 변경 시 메시지 바디를 사용하지 않고 쿼리 파라미터로 요청 HTTP 메시지를 생성한다. 

enctype="multipart-form-data" => boundary 별로 잘라 알아서 요청 메시지를 생성해준다. (파일[바이너리 데이터] 전송)

 

 

HTTP API 데이터 전송

직접 만들어주면 된다. Content-type은 주로 application/json을 사용한다.

 

 

HTTP API 설계 예시

 

 

- HTTP API 컬렉션

   - POST 기반 등록

   - 예) 회원 관리 API 제공

 

- HTTP API - 스토어

   - PUT 기반 등록

   - 정적 컨텐츠 관리, 원격 파일 관리

 

.- HTML FORM 사용

   - 웹 페이지 회원 관리

   - GET, POST만 지원

 

 

회원 관리 시스템

 

회원 목록 /members => GET

회원 등록 /members => POST

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

회원 수정 /members/{id} => PATCH, PUST, POST

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

 

 

POST - 신규 자원 등록 특징

- 클라이언트는 등록될 리소스의 URI를 모른다. 

- 서버가 새로 등록될 리소스 URI를 생성한다. 

- 컬렉션

   - 서버가 고나리하는 리소스 디렉토리

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

 

 

파일 관리 시스템

 

파일 목록 /files => GET

파일 조회 /files/{filename} => GET

파일 등록 /files/{filename} => PUT

파일 삭제 /files/{filename} => DELETE

파일 대량 등록 /files => POST

 

 

PUT - 신규 자원 등록 특징

- 클라이언트가 리소스 URI를 알고 있어야 한다. 

   - 파일 등록 PUT /files/star.jpg

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

- 스토어

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

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

 

 

HTML FORM 사용

 

- HTML FORM은 GET, POST만 사용 가능하다. 

- AJAX 와 같은 기술을 사용하면 해결이 가능하다.

- GET, POST만 지원하므로 제약이 있다. 

 

회원 목록 /members => GET

회원 등록 폼 /members/new => GET

회원 등록 /members/new, /members => POST

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

회원 수정 폼 /members/{id}/edit => GET

회원 수종 /members/{id}/edit, /members/{id} => POST

회원 삭제 /members/{id}/delete => POST

 

 

컨트롤 URI

   - GET, POST만 지원하는 제약을 해결하기 위해 동사로 된 리소스 경로를 사용한다.

   - POST의 /new, /edit, /delete가 컨틀로 URI이다. 

 

 

URI 좋은 설계 개념

 

문서 (document)

- 단일 개념

- 예) /members/100, files/star.jpg

 

컬렉션

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

 

스토어

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

 

컨트롤 URI

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