HTTP 메서드의 속성, 전달방식

YeongMin·2022년 5월 13일
0

HTTP

목록 보기
2/2

추후에 조금 더 정리를 할 필요가 있는 게시물입니다. 🤔

1. URI 설계 기초

서버로 보낼 요청에서 핵심이 되는 리소스가 무엇인지 파악하자.
'정보를 받아오자.'의 경우 정보리소스 가 될 것이다.

그럼 '받아오자'는 어떻게 URI로 나타내야할까?

이를 해결하기 위해 HTTP 프로토콜에서는 메서드를 지원해 해당 리소스에 대한 동작을 지시할 수 있다.

1-1. 주로 사용되는 HTTP 메서드

Method설명
GET리소스 조회
POST리소스 등록
PUT, PATCH리소스 수정
DELETE리소스 삭제

여기서 유일하게 PUT, PATCH만 2개가 같은 기능을 수행한다고 되어 있을 것이다.
그러나 이 둘은 분명 다르게 동작한다.

이것만 알고 넘어가자.

PUT은 리소스 자체를 그대로 덮어씌워서 수정을 하고
PATCH 는 변경이 일어난 부분만 교체를 하는 방식이다.

name : 'ahn0min 인 프로퍼티가 존재할 경우
PUT 을 통해 age 만을 넘겨주면 기존의 name은 사라지고 age만이 남게된다.

이는 PUT은 객체 자체를 덮어씌워 수정하기 때문이다.

PATCH 를 통해 age 를 넘겨주게 되면 기존의 name 과 age를 모두 가질 것이다.

이는 PATCH는 기존의 값을 그대로 가진채로 변경된 부분만 수정, 추가, 삭제 하기 때문

간략히 코드로 결과를 표시하겠다. 이 때 서버와의 통신에 대한 코드는 빠져있다.

const person = { name : 'ahn0min' };

/* 
PUT을 사용한 경우

PUT /person/1

{
    age : 10000,
}
*/

console.log(person); // { age : 10000 }

/* 
PATCH를 사용한 경우

PATCH /person/1

{
    name : "안영민",
    age : 200,
}
*/
console.log(person) // { name: '안영민', age : 200 }

2. HTTP 메서드의 속성

2.1. 안전(Safe)

호출해도 리소스(자원)을 변경하지 않는다.

  • 무한으로 호출했을 때 서버에서 일어나는 장애같은건 안전과는 별도로 생각한다.

2.2. 멱등(Idempotent)

-f(f(x)) = f(x)

  • 1번 호출했을 때와 100번 호출했을 때 결과가 항상 똑같다.
  • 멱등 메서드 종류
    - GET: 조회를 몇번을 해도 리소스를 변경시키지 않는다.
    • PUT: 결과전체를 덮어씌우는 것이다. 한 번 덮어씌우든 여러번 덮어씌우든 똑같다.
    • DELETE: 한번 호출하면 리소스를 삭제한다. 100번 호출해도 해당 리소스는 삭제된 상태이다.
    • POST: 멱등이 아니다!. 두 번 호출했을 때 다른 결과가 발생한다.(상품 주문, 게시물 업로드 등)

2.2.1. 활용

  • 자동 복구 메커니즘

    그런데 조회(GET)을 하고 다른 값으로 데이터를 수정(PUT)한 다음 다시 조회(GET)을 하면 조회(GET)값이 다르지 않나요?

    멱등은 중간에 나 자신의 요청 이외의 다른 요청에 의해 결과가 달라지는 경우까지는 포함하지 않는다.
    그것까지 고려하면 해당 리소스는 바뀌지도않고 삭제도 안되고 평생 건들일 수 없는 존재가 되어버린다.

2.3. 캐시가능

  • 리소스를 캐시해서 사용해도 되는가?
  • 동일한 요청이 발생했을 때 서버로 요청을 보내지 않고 따로 저장을하여 사용할 수 있는가?
  • GET, HEAD, POST, PATCH 모두 캐시가 가능
  • 그러나 실제로는 GET, HEAD 정도만 캐시로 사용한다.

3. 데이터 전달방식

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

  • GET 메소드를 사용
  • 주로 정렬 필터(검색어)

3.2. 메시지 바디르 통한 데이터 전송

  • POST, PUT, PATCH
  • 회원가입, 상품 주문, 리소스 등록, 리소스 변경

3.3. Client => Server

  1. 정적데이터 조회
  • 추가적인 데이터가 필요없다. 즉 쿼리, 파라미터가 필요없다. URL 즉 리소스 경로만 알면 된다.
  1. 동적 데이터 조회
    ex) 구글에서 검색을 할 때 검색어가 무엇인지 언어가 무엇인지 등이 필요함으로 쿼리파라미터를 함께 보내준다.

    https://www.google.com/search?q="훈민정음"&hl=ko
  • 주로 검색, 게시판 목록에서 정렬필터 할 경우
  • GET + 쿼리파라미터
  1. HTML Form을 통한 데이터 전송
    HTML 의 Form 태그를 사용하여 내부에 input 태그의 value를 입력하고 submint event가 발생
  • 웹 브라우저가 HTTP 메시지를 생성해준다.
  • POST일 경우 POST, Host, Content-Type이 존재하고 requst.body에 쿼리 파라미터처럼 생성해 준다.
  • multipart/form-data Form 태그에서 file을 포함하여 서버로 전달할 경우에 사용한다.
  1. HTTP API를 통한 데이터 전송
    웹 클라이언트에서 주로 많이 사용되는 방식, JavaSCript를 통해 통신을 한다.(AJAX)
  • Content-Type: application/json을 주로 사용한다 (거의 표준)
    - TEXT, JSON 등등

4. POST, PUT 차이

4.1. POST

POST는 등록될 리소스의 URI(식별자)를 모른다.

  • 서버가 새롭게 등록되는 리소스의 URI를 생성

  • response의 location에 URI를 같이 담아서 클라이언트로 전송해준다.

    예 : 새로운 회원을 등록할 때 회원정보를 담아서 POST 요청을 보내게 되면 서버에서 회원의 아이디를 만들어(URI 관리) 클라이언트에게 리소스의 URI까지 함께 담아 전달해 주는 상황
    /members [POST]

4.1.1. 컬렉션

  • 서버가 관리하는 리소스 저장소
  • 리소스의 URI를 서버가 알고 관리한다.

4.2. PUT

PUT은 등록될 리소스의 URI를 알고 있고 그것을 서버로 전달할 때 사용한다.

  • 클라이언트가 새롭게 등록되는 리소스의 URI를 같이 전달한다.

    예 : 클라이언트에서 파일을 담아서 업로드 할 경우 해당 파일의 URI를 함꼐 담아 보내주는 상황 서버에서는 클라이언트가 보내준 URI를 통해서 저장을 한다.

4.2.1. 스토어

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

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

    POST방식 vs PUT방식
    컬렉션 vs 스토어

4.3. 컨트롤 URI

Form tag의 경우 GET, POST만 사용이 가능하다.

  • 수정, 삭제하고 싶을 때도 POST를 이용해서 해결해야한다.
  • /new, /edit, /delete가 컨트롤 URI 이다.
  • HTTP method 로 최대한 해결하고 해결하지 못할 때가 되서야 사용하도록 하자.
profile
Front-End 안영민

0개의 댓글