CS/HTTP

[HTTP] HTTP 메서드

쿠릉쿠릉 쾅쾅 2022. 2. 28. 22:20
728x90

 

 

API URI 설계

  • API URI 설계에 있어서 가장 중요한 것은 리소스 식별이다.
  • 리소스는 회원을 등록하고 수정하고 조회하는게 리소스가 아니다.
    • 예) '미네랄을 캐라' 명령어에서 미네랄 그 자체가 리소스다.
    • 그러므로 회원 가입, 회원 조회 등등 모두 회원 그 자체가 리소스다.
  • 리소스를 URI에 매핑해야 한다.

 

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

  • 회원 목록 조회 : /members
  • 회원 조회 : /members/{id}
  • 회원 등록 : /members/{id}
  • 회원 수정 : /members/{id}
  • 회원 삭제 : /members/{id}

참고로 계층 구조상 상위를 컬렉션으로 보고 복수단어 사용을 권장한다.

예) member → members

 

리소스를 식별하고 URI 계층 구조로 나눴으나 조회, 등록, 수정, 삭제에 대해서 구별할 수가 없다.

그럴 때는 리소스를 대상으로 행위를 분리해야 한다.

 

 

🔍 리소스와 행위 분리

  • 리소스 : 회원
  • 행위 : 조회 / 등록 / 삭제 / 변경
    • 행위는 HTTP 메서드다.

 

 

 

 

HTTP 메서드

 

 

🔍 HTTP 메서드 종류

 

💡 주요 메서드

  • GET : 리소스 조회
  • POST : 요청 데이터 처리, 주로 등록에 사용
  • PUT : 리소스를 대체, 해당 리소스가 없으면 생성
  • PATCH : 리소스 부분 변경
  • DELETE : 리소스 삭제

 

💡 기타 메서드

  • HEAD : get과 동일하지만 메시지 부분을 제외하고, 상대 줄과 헤더만 반환
  • OPTIONS : 대상 리로스에 대한 통신 가능 옵션(메서드)을 주로 설명 (주로 CORS에서 사용)
  • CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
  • TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

 

 

🔍 GET

  • 리소스 조회
  • 서버에 전달하고 싶은 데이터를 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달한다.
  • 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않는다.

 

💡 GET 동작 방식

① 리소스 조회 - 메시지 전달

ㅁ

② 리소스 조회 - 서버 도착

 

③ 리소스 조회 - 응답 데이터

 

 

 

🔍 POST

  • 요청 데이터 처리
  • 클라이언트가 서버로 메시지 바디를 통해 요청 데이터를 전달한다.
  • 서버는 요청 데이터를 처리한다.
    • 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
  • 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용한다.

 

💡 POST 동작 방식

① 리소스 등록 - 메시지 전달

 

② 리소스 등록 - 신규 리소스 생성

 

 

③ 리소스 등록 - 응답 데이터

 

 

💡 POST의 요청 데이터 처리

  •  스펙 : POST 메서드는 대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청한다.
  • HTML 양식에 입력된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공한다.
    • 예) HTML FORM에 입력한 정보로 회원 가입, 주문 등에서 사용
  • 게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메시지 게시
    • 예) 게시판 글쓰기, 댓글 달기
  • 서버가 아직 식별하지 않은 새 리소스 생성
    • 예) 신규 주문 생성
  • 기존 자원에 데이터 추가
    • 예) 한 문서 끝에 내용 추가하기

 

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

→ 정해진 것이 없고, 모든 요청을 마음대로 할 수 있다는 뜻!

 

 

💡 POST 기능

  • 새 리소스 생성(등록)
    • 서버가 아직 식별하지 않은 새 리소스 생성
  • 요청 데이터 처리
    • 단순히 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우
    • 예) 주문에서 결제 완료 → 배달 시작 → 배달 완료 처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우
    • POST의 결과로 새로운 리소스가 생성되지 않을 수도 있다.
    • 예) POST/orders/{orderId}/start-delicery  (컨트롤 URI)
      • 되도록 URI에는 리소스만 식별하도록 해야하지만, 100퍼센트 그렇게 설계하는 것은 불가능하다.
  • 다른 메서드로 처리하기 애매한 경우
    • 예) JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우
    • 애매하면 POST를 사용할 것

 

 

🔍 PUT

  • 리소스를 대체한다.
    • 리소스가 있으면 대체한다.
    • 리소스가 없으면 새로 생성한다.
    • 쉽게 이야기해서 기존의 것을 덮어버린다.
  • 클라이언트가 리소스를 식별한다.
    • 클라이언트가 리소스 위치를 알고 URI를 지정한다.
    • POST와 차이점이다. (POST는 클라이언트가 리소스 위치를 알지 못한다.)

 

💡 PUT 동작 방식 (리소스가 있는 경우)

 

 

 

💡 PUT 동작 방식 (리소스가 없는 경우)

 

 

 

💡 PUT은 리소스를 완전히 대체한다.

 

 

 

 

🔍 PATCH

  • 리소스 부분을 변경한다.
  • 한마디로 전체 변경이 아닌 해당하는 부분만 변경이다.

 

💡  PATCH 동작 방식 - 리소스 부분 변경

 

 

 

 

🔍 DELETE

  • 리소스 제거

 

 

💡 DELETE 동작 방식 - 리소스 제거

 

 

 

 

 

 

HTTP 메서드 속성

  • 메서드 속성으로 3가지가 있다.
    • 안전 (Safe Methods)
    • 멱등 (Idempotent Methods)
    • 캐시 가능 (Cacheable Methods)

 

 

🔍 안전 (Safe)

  • 호출해도 리소스가 변경하지 않아야 안전한 것이다.
  • 안전 조건은 호출시 해당 리소스가 변하냐 변하지 않냐 이다.
  • get 방식이 안전하다.

 

 

🔍 멱등 (Idempotent

  • 한 번 호출하든 두 번 호출하든 100번 호출 하든 결과가 똑같아야 멱등이다.
  • f(f(x)) = f(x)
  • 멱등 메서드
    • GET : 여러 번 조회해도 같은 결과가 조회된다.
    • PUT : 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
    • DELETE : 결과를 삭제한다. 따라서 같은 요청을 여러 번 해도 삭제된 결과는 같다.

POST는 멱등이 아니다. 두 번 호출 하면 같은 결제가 중복해서 발생할 수 있기에 같은 결과가 나오지 않는다.

 

💡 멱등 활용

  • 자동 복구 메커니즘
  • 서버가 TIMEOUT 등으로 정상 응답을 못 주었을 때, 클라이언트가 같은 요청을 다시 해도 되는지 판단의 근거를 제공한다.

 

💡 멱등은 외부 요인을 고려하지 않는다.

  • 예시
    • 사용자 1 : GET → username : A, age : 20
    • 사용자 2 : PUT → username: A, age: 30
    • 사용자 1 : GET → username: A, age : 30  (사용자2의 영향으로 바뀐 데이터가 조회된다.)
  • 이처럼 멱등은 외부 요인으로 중간에 리소스가 변경되는 것까지 고려하지 않는다. 그러므로 GET은 멱등 메서드다.

 

 

🔍 캐시 가능 (Cacheable)

  • GET / HEAD / POST / PATCH 는 캐시 가능하다.
  • 실제로 GET / HEAD 정도만 캐시로 사용한다.
    • POST / PATCH는 본문 내용까지 캐시 키로 고려해야 하기에 구현이 쉽지 않아서 잘 안쓰인다.

 

💡 캐시란

  • 캐싱은 애플리케이션의 처리 속도를 높여준다.
  • 이미 가져온 데이터나 계산된 결과값의 복사본을 웹 로컬에 저장함으로 써 똑같은 요청이 있을 경우 저장된 복사본을 불러와서 처리 속도를 높여준다.
  • 사용자(클라이언트)가 웹 사이트(서버)에 접속할 때, 정적 컨텐츠(이미지, js, css 등)를 특정 위치(클라이언트, 네트워크 등)에 저장하여 웹 서버에 해당 컨텐츠를 매번 요청하여 받는 것이 아니라, 특정 위치에서 불러옴으로써 사이트 응답 시간을 줄이고, 서버 트래픽 감소 효과를 볼 수 있다.

 

 

 

 

HTTP 메서드 활용

  • 클라이언트에서 서버로 데이터 전송
  • HTTP API 설계

 

 

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

💡 데이터 전달 방식은 크게 2가지다.

  • 쿼리 파라미터를 통한 데이터 전송
    • GET 방식
    • 주로 필터 정렬 (검색어)
  • 메시지 바디를 통한 데이터 전송
    • POST / PUT / PATCH 방식
    • 회원 가입, 상품 주문, 리소스 등록, 리소스 변경

 

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

  • 정적 데이터 조회
    • 이미지, 정적 텍스트 문서
  • 동적 데이터 조회
    • 주로 검색, 게시판 목록에서 정렬 필터 (검색어) 
  • HTML Form을 통한 데이터 전송
    • 회원 가입, 상품 주문, 데이터 변경
  • HTTP API를 통한 데이터 전송
    • 회원 가입, 상품 주문, 데이터 변경
    • 서버 to 서버 / 앱 클라이언트 / 웹 클라이언트(Ajax) 

 

 

🔍 정적 데이터 조회

  • 쿼리 파라미터를 사용하지 않는다.
  • 이미지, 정적 텍스트 문서를 대상으로 사용한다.
  • 조회할 때 GET 방식을 사용한다.
  • 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능하다.

 

 

🔍 동적 데이터 조회

  • 주로 검색, 게시판 목록에서 정렬 필터(검색어)에서 사용한다.
  • 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용한다.
  • 조회는 GET 방식 사용
  • GET은 쿼리 파라미터를 사용해서 데이터를 전달한다.

 

 

🔍 HTML Form 데이터 전송

💡 POST 전송 - 저장

  • Content-Type은 request에 실어 보내는 데이터(body) 타입의 정보를 표현한 것이다.
  • 쿼리 파라미터 형식으로 데이터를 만든 후 HTTP 바디 메시지에 넣는다.

 

💡 GET 전송 - 저장

  • get 방식은 메시지 바디를 사용하지 않는다.
  • 헤더 부분의 url 경로에 쿼리파라미터가 들어간다.
  • 참고로 get 방식은 회원 가입, 정보 저장등 리소스 변경이 발생하는 곳에서는 사용하면 안된다.

 

💡 GET 전송 - 조회

 

💡 multipart/form-data

  • 여러 컨텐츠 타입의 데이터를 보낼 때 사용한다.
  • 주로 파일 업로드 같은 바이너리 데이터를 보낼 때 사용한다.

 

✔ 정리

  • HTML Form에서 submit시 POST 전송
    • 예) 회원 가입, 상품 주문, 데이터 변경 할 때 주로 쓰인다.
    • Content-Type : application/x-www-form-urlencoded 이다.
    • Form의 내용을 서버로 메시지 바디를 통해서 전송한다.
      • 데이터가 key=value 형식으로 쿼리 파라미터 형식이다.
    • 전송 데이터를 url encoding으로 처리한다.
      • 예) abc김 → abc%EA%B9%80
  • HTML Form은 GET 전송으로 가능하다.
  • Content-Type : multipart/form-data
    • 파일 업로드 같은 바이너리 데이터 전송시 사용한다.
    • 다른 종류의 여러 파일과 폼의 내용을 함께 전송 가능하다.
  • HTML Form 전송은 GET / POST 만 지원한다.

 

 

🔍HTTP API 데이터 전송

  • 서버 to 서버
    • 백엔드 시스템 통신
  • 앱 클라이언트
    • 아이폰, 안드로이드
  • 웹 클라이언트
    • HTML에서 Form 전송 대신 자바 스크립트를 통한 통신에 사용한다. (AJAX)
    • 예) React, VueJs 같은 웹 클라이언트와 API 통신
  • POST / PUT / PATCH 방식으로 메시지 바디를 통해 데이터를 전송한다.
  • 조회할 때는 GET 방식으로 항상 쿼리 파라미터로 데이터를 전달한다.
  • Content-Type은 주로 application/json으로 사용한다. (사실상 표준이다.)

 

 

 

 

HTTP API 설계 예시

  • HTTP API - 컬렉션
    • POST 기반 등록
    • 예) 회원 관리 API 제공
  • HTTP API - 스토어
    • PUT 기반 등록
    • 예) 정적 컨텐츠 관리, 원격 파일 관리
  • HTML FORM 사용
    • 웹 페이지 회원 관리
    • GET / POST 만 지원한다.

 

 

🔍 회원 관리 시스템

💡 API 설계 - POST 기반 등록

  • (GET) 회원 목록 : /members
  • (POST) 회원 등록 : /members 
  • (GET) 회원 조회 : /members/{id} 
  • (PATCH / PUT / POST) 회원 수정 : /members/{id} 
  • (DELETE)회원 삭제 : /members/{id} 

 

💡 POST - 신규 자원 등록 특징

  • 클라이언트는 등록될 리소스의 URI를 모른다.
    • 예) 회원 등록 : /members
  • 서버가 새로 등록된 리소스 URI를 생성해준다.
    • 예) Location : /members/100
  • 이러한 스타일의 관리를 컬렉션(Collection)이라고 한다.
    • 서버가 관리하는 리소스 디렉토리다.
    • 서버가 리소스의 URI를 생성하고 관리한다.
    • 여기서 컬렉션은 /members 다.

 

 

🔍 파일 관리 시스템

💡 API 설계 - PUT 기반 등록

  • (GET) 파일 목록 : /files
  • (GET) 파일 조회 : /files/{filename}
  • (PUT) 파일 등록 : /files/{filename}
  • (DELETE) 파일 삭제 : /files/{filename}
  • (POST) 파일 대량 등록 : /files

 

💡 PUT - 신규 자원 등록 특징

  • 클라이언트가 리소스 URI를 알고 있어야 한다.
    • (PUT) 파일 등록 : /files/{filename}
    • 예) /files/star,jpg
  • 클라이언트가 직접 리소스의 URI를 지정한다.
  • 이러한 스타일의 관리를 스토어(Store)라고 한다.
    • 클라이언트가 관리하는 리소스 저장소다.
    • 클라이언트가 리소스의 URI를 알고 관리한다.
    • 여기서 스토어는 /files 다.

 

 

🔍 HTML FORM 사용

  • HTML FORM은 GET /POST만 지원한다.
  • AJAX 같은 기술을 사용해서 해결 가능하다.
  • 컨트롤 URI
    • HTML FORM은 GET / POST 만 지원 하므로 제약이 있다.
    • 이런 제약을 해결하기 위해 컨트롤 URI를 통해 동사로 된 리소스 경로를 사용한다.
    • POST의 /new, /edit/, delete 가 컨트롤 URI다.
    • HTTP 메서드로 해결하기 애매한 경우 사용한다. (HTTP API 포함)
    • 실무에서 자주 쓰인다.
    • 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행할 때 쓰인다.
    • 예) /members/{id}/delete

 

💡 회원 관리 시스템

  • (GET) 회원 목록 : /members
  • (GET) 회원 등록 폼 : /members/new
  • (POST) 회원 등록 : /members/new,  /members
  • (GET) 회원 조회 : /members/{id}
  • (GET) 회원 수정 폼 : /members/{id}/edit 
  • (POST) 회원 수정 : /members/{id}/edit,  /members/{id}
  • (POST) 회원 삭제 : /members/{id}/delete

 

 

🔍 참고하면 좋은 URI 설계 개념

 

💡 문서 (documnet)

  • 단일 개념(파일 하나, 객체 인스턴스, 데이터 베이스 row)
  • 예) /members/100, /files/star.jpg

 

💡 컬렉션(collection)

  • 컬렉션은 서버가 관리하는 리소스 디렉터리다.
  • 서버가 리소스의 URI를 생성하고 관리한다.
  • 예) /members

 

💡 스토어(store)

  • 스토어는 클라이언트가 관리하는 자원 저장소다.
  • 클라이언트가 리소스의 URI를 알고 관리한다.
  • 예) /files

 

 

💡 컨트롤러(controller), 컨트롤 URI

  • 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행할 때 쓰인다.
  • 동사를 직접 사용한다.
  • 예) /members/{id}/delete

 

 

 

 

 

👀 참고 자료

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

 

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

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

www.inflearn.com

 

https://hahahoho5915.tistory.com/33

 

웹 캐시(WEB Cache)란 무엇인가?(특징)

개요 > 웹 캐시(WEB Cache)가 무엇(What)인가? > 웹 캐시(WEB Cache)를 사용하는 이유(Why)? 멋대로 요약 캐싱 기본 개념 : 캐싱(Caching)은 애플리케이션의 처리 속도를 높여준다. 이미 가져온 데이터나.

hahahoho5915.tistory.com

 

https://gist.github.com/jays1204/703297eb0da1facdc454

 

Http Method는 POST, Content-Type이 application/x-www-form-urlencoded인 경우 body를 encoding하는게 맞을까?

Http Method는 POST, Content-Type이 application/x-www-form-urlencoded인 경우 body를 encoding하는게 맞을까? - postbodyEnc.md

gist.github.com

 

728x90