4.모든 개발자를 위한 HTTP 웹 기본지식 - 김영한 -inflearn : < HTTP 메서드>

YP J·2022년 7월 29일
0

inflearn-http-김영한

목록 보기
5/7
  • HTTP API 를 만들어 보자
  • HTTP 메서드 - GET, POST
  • HTTP 메서드 - PUT, PATCH, DELETE
  • HTTP 메서드의 속성

HTTP API 를 설계해보자 (회원 정보 관리 API)

  • 요구사항
    • 회원 목록 조회
    • 회원 조회
    • 회원 등록
    • 회원 수정
    • 회원 삭제

API URL 설계 ( Uniform Resource Identifier )

  • 회원 목록 조회 -> /read-member-list
  • 회원 조회 -> /read-member-by-id
  • 회원 등록 -> / ,,,
  • 회원 수정 ,,,
  • 회원 삭제 ,,,

URI 설계에서 가장 중요한 것은 리소스 식별 이다

  • 리소스 란?
    • 회원을 등록하고 수정하고 조회하는게 리소스가 아니다.
    • 예) 미네랄을 캐라 -> 미네랄이 리소스
    • 회원이라는 개념 자체가 바로 리소스 이다.
  • 리소스를 어떻게 식별 하는게 좋을까?
    • 회원을 등록하고 수정하고 조회하는것을 모두 배제
    • 회원이라는 리소스만 식별하면 된다.-> 회원 리소스를 URI에 매핑

->

  • 회원 목록 조회 -> /members
  • 회원 조회 -> /members{id} 얘랑
  • 회원 등록 -> /members{id} 얘를 어떻게 구분하지??
  • 회원 수정 ->
  • 회원 삭제 ->

리소스와 행위를 분리

가장 중요한 것은 리소스를 식별 하는것.

  • URI는 리소스만 식별 !
  • 리소스와 해당 리소스를 대상으로 하는 행위를 분리
    • 리소스 : 회원
    • 행위 : 조회, 등록, 삭제, 변경
  • 리소스는 명사, 행위는 동사 ( 미네랄을 캐라)
  • 행위(메서드) 는 어떻게 구분? -> HTTP메서드 가 구분해준다.

HTTP메서드 ! - GET, POST

:클라이언트가 서버에 요청을 할때 기대하는 행동
리소스 ~: 레프리젠테이션

  • GET: 리소스 조회 ( 리소스 줘!)
  • POST: 서버는 데이터를 담아서 요청자에게 줘야한다, 요청데이터 처리, 주로 등록에 사용
  • PUT: 리소스 대체, 해당 리소스가 없으면 생성 ( 기존의 리소스가 있으면 덮어버린다.)
  • PATCH: 리소스 부분 변경
  • DELETE: 리소스 삭제

기타 메서드

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

  • OPTIONS: 대상 리소스에 대한 통신 가능 옵션 (메서드)을 설명 (주로 CORS에서 사용)

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

  • TRACE: 대상 리소스에 대한 경로를 따라 메세지 루프백 테스트 수행
    CONNECT, TRACE 는 거의 사용 안 한다.

    GET

    /search?q=hello&hl=ko HTTP/1.1Host:www.google.com

    • 해당 URL에 있는 자원을 주세요 !

  • 리소스 조회

  • 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달

    • GET에서 메세지 바디를 전달할수 있다 ( 최근 스펙에서 막지 않는다. But 실무에서는 하지 않는다. 필요한 경우 query파라미터나 스트링으로 전달 한다.
    • 왜냐면 중간에 GET에 메세지 바디 전달하는걸 지원하지 않는 경우가 많다.

  • 클라이언트 -> 서버 : GET으로

  • 서버 -> 클라이언트 : GET::Response 서버에서 응답 데이터로 만들어서 클라이언트에 보내준다 (이걸 데이터를 가지고 그린다.)

POST

: 클라이언트 에서 서버에 요청을 보낼때 데이터를 줘서 그 데이터를 서버에서 처리해줘 !

POST/members HTTP/1.1
Content-Type: application/json
{
	"username":"hello",
    "age" : 20
}

  • 요청 데이터 처리

  • 메세지 바디를 통해 서버로 요청 데이터 전달

  • 서버는 요청 데이터를 처리

    • 메세지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.

  • 주로 전달된 데이터로 리소스 등록, 프로세스 처리에 사용

  • 클라이언트 -> 서버 : POST

POST/members HTTP/1.1
Content-Type: application/json
{
	"username":"hello",
    "age" : 20
}
  • 서버 -> 클라이언트 : POST::REsponse
HTTP/1.1 201 Created     (201 은 이게 어디에 저장 되어있는지 Location 도 보냄, 그게 아닌 200 으로 해도됨)
Content-Type: application/json
Content-Length:34
Location:/members/100

{
	"username":"hello",
    "age" : 20
}

그럼 POST는 요청 데이터를 어떻게 처리한다는 뜻일까?

예시

  • 스펙: POST 메서드는 대상 리소스가 리소스의 고유 한 의미 체계에 따라 요청에 포함 된 표현을 처리하도록 요청합니다 ( 구글 번역 이라 이해 어렵)

  • 예를 들어 POST는 다음과 같은 기능에 사용 됩니다.

    • HTML양식에 입력 된 필드와 같은 데이터 블록을 처리하는 데이터 처리 프로세스에 제공
      • 예) HTML FOrM에 입력한 정보로 회원 가입, 주문 등에 사용
    • 게시판, 뉴스그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메세지 게시
      • 예) 게시판 글쓰기, 댓글 달기
    • 서버가 아직 식별하지 않은 새 리소스 생성
      • 예) 신규 주문 생성
    • 기존 자원에 데이터 추가
      • 예) 한 문서 끝에 내용 추가하기

    정리 : 이 리소스 URL 에 POST 요청이 오면 요청이 어떻게 처리할지 리소스마다 따로 정해야함-> 정해진게 없다는 뜻

    POST 정리

    1. 새리소스 생성(등록)
    • 서버가 아직 식별하지 않은 새 리소스 생성
    1. 요청 데이터 처리
    • 단순히 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야한다. (서버에서 변화가 일어난다)
      • 예) 주문에서 결제완료 -> 배달시작 -> 배달 완료 처럼 단순한 값 변경을 넘어 프로세스의 상태가 변경되는 경우
    • POST의 결과로 새로운 리소스가 생성 되지 않을 수 도 있음
      • 예) POST/orders/{oderId}/start-delivery(컨트롤 URI)
      • 어? 아까 설명할때 미네랄을 캐라해서 메네랄만 캐라하고 ~그건 이상적인거고 어쩔수 없을땐 이렇게 Control URI 쓴다.

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

    • 예) JSON 으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우
    • 애매하면 POST

PUT

PUT/members/100 HTTP/1.1
Content-Type: application/json

{
	"username":"hello",
    "age":20
}

  • 리스소를 대체

    • 리소스가 있으면 대체
    • ''' 없으면 생성
    • 쉽게 이야기 해서 덮어버림

  • 중요! 클라이언트가 리소스를 직별

    • 클라이언트가 리소스 위치를 알고 URI 지정
    • POST와 차이점이다

  • 클라이언트 -> 서버 : PUT 을 보내면 

PUT/members/100 HTTP/1.1
Content-Type: application/json

{
	"username":"hello",
    "age":20
}
  • 서버는 기존에 있던 리소스를 대체 한다.
    members/100
{
	"username":"old", -> "hello"
    "age":50 -> 20
}
  • 주의! 리소스를 완전히 대체한다. 
PUT/members/100 HTTP/1.1
Content-Type: application/json

{
    "age":20 
}
  • 이렇게 username필드 없이 age만 보내면
  • 서버에선 username필드가 삭제 된다.
    members/100
{
	"age":20
}

따라서 PUT은 리소스를 수정하는것이 아닌 갈아 치우는 것이다.

수정 하는 경우로 사용 하고 싶을땐? -> PATCH!

PATCH ( 패치 지원 하지 않는 경우 그냥 POST 쓰면 된다~ )

PATCH/members/100 HTTP/1.1
Content-Type: application/json

{
    "age":20 
}
  • 서버에서
    members/100
{
	"username": "old",
    "age":20
}

DELETE 는 리소스 삭제

HTTP 메서드의 속성

  • 안전(Safe Methods)
  • 멱등(Idempotent Methods)
  • 캐시가능(Cacheable Methods)

안전

  • 호출해도 리소스를 변경하지 않는다.
    • Q: 그래도 계속 호출해서 로그같은게 쌓여서 장애가 발생하면?
    • A: 안전은 해당 리소스만 고려한다. 그런건 고려 하지 않는다.

멱등

  • f(f(f(f(f(f(f...(x)...)) = f(x)
  • 한번 호출하든 여러번 호출하든 결과가 똑같아야한다.
  • 멱등 메서드
    • GET: 조회
    • PUT: 결과 대체. 여러번 요청해도 최종 결과는 똑같다.
    • DELETE: 결과 삭제 , 삭제된 결과는 똑같다.
    • (X) POST:는 멱등이 아니다! 두번 호출하면 같은 결제가 중복해서 발생할수 있다.
  • 멱등의 활용
    • 자동 복구 메커니즘
      • 예) DELETE를 했는데 응답이 없다 그럼 클라이언트에서 자동으로 재시도 한다.
    • 서버가 TIMEOUT 등으로 정상 읍답을 못 주었을때, 클라이언트가 같은 요청을 다시해도 되는가? 의 판단 근거가 된다.
    • 왜냐면 또 요청해도 결과가 같으닌까!
  • Q:재요청 중간에 다른 곳에서 리소스를 변경해 버리면?
    • 사용자1: GET->username:A,age:20
    • 사용자2: PUT->username:A,age:30
    • 사용자1: GET->username:A,age:30 -> 사용자2의 영향으로 바뀐 데이터 조회
  • A:멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려 하지 않는다

캐시가능

캐시: 내 로컬에 이미지나 그런걸 캐시화 해놓은것. 다음에 또 요청할때 서버에서 가죠오는게 아니라 로컬에서 가져 오는것.

  • 응답 결과 리소스를 캐시해서 사용해도 되는가?
  • GET, HEAD, POST, PATCH 캐시 가능
  • 실제로는 GET, HEAD 정도만 캐시로 사용
    • POST,PATCH는 본문 내용 까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않다.
profile
YP J
be pro
이전 포스트

3.모든 개발자를 위한 HTTP 웹 기본지식 - 김영한 -inflearn

다음 포스트

5.모든 개발자를 위한 HTTP 웹 기본지식 - 김영한 -inflearn : < HTTP 메서드 활용>

0개의 댓글