본문 바로가기

문과 코린이의, [WEB] 기록/문과 코린이의, [HTTP] 기록

[문과 코린이의 IT 기록장] HTTP - HTTP메서드 (HTTP API를 간단하게 작성해보기 - 문제 파악하기, HTTP 메서드 종류)

반응형

[문과 코린이의 IT 기록장] HTTP - HTTP메서드 (HTTP API를 간단하게 작성해보기 - 문제 파악하기, HTTP 메서드 종류)

[문과 코린이의 IT 기록장] HTTP - HTTP메서드 (HTTP API를 간단하게 작성해보기 - 문제 파악하기, HTTP 메서드 종류)

 


 

 

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

실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., - 강의 소개 | 인프런...

www.inflearn.com

2022.05.24 - [문과 코린이의, [WEB] 기록/문과 코린이의, [HTTP] 기록] - [문과 코린이의 IT 기록장] HTTP - 인터넷 네트워크 (인터넷 통신, IP, TCP/UDP, PORT, DNS)

 

[문과 코린이의 IT 기록장] HTTP - 인터넷 네트워크 (인터넷 통신, IP, TCP/UDP, PORT, DNS)

[문과 코린이의 IT 기록장] HTTP - 인터넷 네트워크 (인터넷 통신, IP, TCP/UDP, PORT, DNS) 모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의 실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTT..

vansoft1215.tistory.com

2022.05.25 - [문과 코린이의, [WEB] 기록/문과 코린이의, [HTTP] 기록] - [문과 코린이의 IT 기록장] HTTP - URI와 웹 브라우저 요청 흐름 (URI, 웹 브라우저 요청 흐름)

 

[문과 코린이의 IT 기록장] HTTP - URI와 웹 브라우저 요청 흐름 (URI, 웹 브라우저 요청 흐름)

[문과 코린이의 IT 기록장] HTTP - URI와 웹 브라우저 요청 흐름 (URI, 웹 브라우저 요청 흐름) 모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의 실무에 꼭 필요한 HTTP 핵심 기능과 올바

vansoft1215.tistory.com

2022.05.30 - [문과 코린이의, [WEB] 기록/문과 코린이의, [HTTP] 기록] - [문과 코린이의 IT 기록장] HTTP - HTTP (HTTP란?, 클라이어트 - 서버 구조, 무상태 프로토콜 (스테이스리스(Stateless)), 비연결성 (Connectionless), HTTP 메시지)

 

[문과 코린이의 IT 기록장] HTTP - HTTP (HTTP란?, 클라이어트 - 서버 구조, 무상태 프로토콜 (스테이스

[문과 코린이의 IT 기록장] HTTP - HTTP (HTTP란?, 클라이어트 - 서버 구조, 무상태 프로토콜 (스테이스리스(Stateless)), 비연결성 (Connectionless), HTTP 메시지) 모든 개발자를 위한 HTTP..

vansoft1215.tistory.com


1. HTTP API를 간단하게 작성해보기 - 문제 파악하기

API URI(Uniform Resource Identifiere)를 설계해보자

 

ex 1. 회원 정보 관리하는 API를 설계해라. (5가지 요구사항 존재)

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

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

- 회원 등록 /create-member

- 회원 수정 /update-member

- 회원 삭제 /delete-member

=> 이는 좋은 URI 설계가 아니다.

=> URI 설계에서 가장 중요한 것은, 리소스를 식별하는 것. 즉 리소스를 행위와 분리하는 것이다.

 * 리소스(=Resource = Representation)란 = 명사 / 행위 = 동사

 * 위에서 리소스는 회원이라는 개념 자체이다. 즉 회원이라는 리소스만 식별해, URI에 매핑하면 된다.

 

ex 2. 

- 회원 목록 조회 /mbmers

- 회원 조회 /members/{id} // {id}는 사용자 개인이 가지고 있는 고유id번호를 의미

- 회원 등록 /members/{id}

- 회원 수정 /members/{id}

- 회원 삭제 /members/{id}

=> 문제 발생 : 회원 조회, 등록, 수정, 삭제를 구분할 수 없게 된다.

=> 즉 URI에는 명사인 리소스만 사용하므로, 이를 제외한 동사인 행위(메서드)를 구분할 수 있는 방법을 찾아야 하는데, 이는 HTTP 메서드로 해결 가능하다.

 


2. HTTP 메서드 종류

[ 주요 메서드 ]

- GET : 리소스 조회

- POST : 데이터를 클라이언트가 항상 담아서 보내며, 이를 처리해달라고 요청한다. (주로 등록에 사용)

- PUT : 클라이언트에서 서버로 보내는 리소스로 대체해달라고 요청하는 것이다. 해당 리소스가 기존에 없다면 신규 생성된다. (파일을 폴더에 넣는 행위와 비슷하다)

- PATCH : 리소스를 부분적으로 변경한다. (특정 필드 몇 개만 변경할 시 사용한다.)

- DELETE  : 리소스를 삭제한다.

 

[ 기타 메서드 ]

- HEAD : GET과 동일하지만 메세지 body 부분을 제외하고, 상태 줄과 헤더만 반환한다.

- OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)를 설명해준다. (주로 CORS에서 사용한다.)

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

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


1) GET

- 리소스를 조회하는 것이다.

 * GET도 메시지 바디를 이용해서 전달할 수 있지만, 권장하지는 않는다.

클라이언트 -> 서버 GET 전달
서버 -> 클라이언트 GET 응답

 


2) POST

- 클라이언트가 서버에게 요청 데이터를 전달해, 처리해달라고 하는 것이다.

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

- 주로, 전달된 데이터로 신규 리소스 등록 / 프로세스 처리에 사용된다.

클라이언트 -> 서버

 

서버 -> 클라이언트

 * 201번으로 응답 데이터를 보낼 때는, Location(이 리소스가 신규 생성된 경로)도 함께 보낸다.

 

 

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

주로 POST는 다음과 같은 기능에 사용된다.

a. HTML 양식에 입력 된 필드와 같은 데이터 블록을, 데이터 처리 프로세스에 제공한다.

 ex. HTML FORM에 입력한 정보로 회원 가입, 주문 등에 사용한다.

b. 게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메시지를 게시한다.

 ex. 게시판 글쓰기, 댓글 달기

c. 서버가 아직 식별하지 않은 새 리소스를 생성한다,

 ex. 신규 주문 생성

d. 기존 자원에 데이터를 추가한다.

 ex. 한 문서 끝에 내용 추가하기

 

=> 즉, 이 리소스 URI에 POST요청이 오면, 해당 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 한다.

 

 

[ POST를 사용하는 경우 정리 ]

1. 새 리소스 생성 (등록) : 서버가 아직 요청하지 않은 새 리소스 생성

2. 요청 데이터 처리

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

 ex. 주문에서 결제완료 -> 배달시작 -> 배달완료처럼 단순히 값 변경을 넘어, 프로세스의 상태가 변경되는 경우

- 리소스만 가지고 URI를 모두 설계할 수 없다. 따라서 어쩔 수 없는 경우에는 POST를 통해 컨트롤 URI로 설계하면 된다.

 ex. POST /orders/{orderID}/start-delivery(컨트롤 URI)

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

 ex. JSON으로 조회하는 데이터를 넘겨야하는데, 쿼리가 아니라 직접 메시지를 넘겨서 조회하고 싶을 경우, 즉 애매할 경우 POST를 사용한다. => 그러나 조회할 때는 일반적으로 GET을 쓰는 것이 더 좋다. (캐싱이 가능하기 때문에)


3) PUT

- 리소스를 대체하는 역할을 한다. 리소스가 존재하면 대체하며, 없다면 새로 생성한다.

 

a. 리소스가 존재하는 경우

b. 리소스가 없는 경우

=> 주의점 : 리소스를 완전히 대체한다.


4) PATCH

- 리소스를 부분 변경할 때 (수정할 때) 사용한다.

 * 서버에 따라 http패치가 못 받아들이는 경우도 있는데, 이 경우에는 POST를 사용하면 된다.

 


5) DELETE

- 해당 리소스를 제거한다.

 


3. HTTP 메서드의 속성

HTTP 메소드 요청에 Body가 있음 응답에 Body가 있음 안전 멱등 캐시 가능
GET 아니오
POST 아니오 아니오
PUT 아니오 아니오
PATCH 아니오 아니오
DELETE 아니오 아니오 아니오

1) 안전 (Safe Methods)

- 호출해도 리소스가 변경되지 않는다.

 * GET만 안전함. / POST, DELETE, PUT, PATCH 모두 변경가능성 존재

 ** 안전은 해당 리소스까지 고려하며, 로그 축적으로 인한 장애 발생과 같은 부분은 고려하지 않는다.

 

2) 멱등 (Idempotent Methods)

- 몇 번 호출하던 결과가 같다.

- 자동 복구 매커니즘에서 활용 : 서버가 정상 응답을 못할 때, 클라이언트가 같은 요청을 다시 시도해도 되는가와 관련한 판단 근거가 된다.

 * GET, PUT, PATCH, DELETE 모두 멱등하다 / POST는 결과가 중복해서 발생할 수 있다.

 ** 멱등은 외부 요인으로, 중간에 리소스가 변경되는 것까지 고려하지 않는다.

 

3) 캐시가능 (Cacheable Methods)

- 응답 결과 리소스를 캐시에서 사용할 수 있지 여부를 말한다.

 * 캐시 사용 예시 : 웹브라우저에서 어떤 한 이미지를 경우, 그 이미지를 다시 다운받으려면 시간이 많이 걸린다는 단점을 극복하기 위해, 로컬 pc에서 저장하도록 구현한 방법

 * GET / HEAD / POST / PATCH 모두 캐시가 가느하지만, 실제로는 GET / HEAD정도만 캐시로 사용한다. (나머지는 구현이 쉽지 않음)

 


* 유의사항
- 아직 공부하고 있는 문과생 코린이가, 정리해서 남겨놓은 정리 및 필기노트입니다.
- 정확하지 않거나, 틀린 점이 있을 수 있으니, 유의해서 봐주시면 감사하겠습니다.
- 혹시 잘못된 점을 발견하셨다면, 댓글로 친절하게 남겨주시면 감사하겠습니다 :)
반응형