등딱지빌런

등딱지빌런

안녕하세요. 정인호입니다.

Chapter4. HTTP Method

Date:     Updated:

카테고리:

태그:

인프런에 있는 김영한님의 모든 개발자를 위한 HTTP웹 기본 지식 강의를 듣고 정리한 내용입니다.
중간에 등장하는 ppt 내용들은 모두 강의자료를 캡처한 것입니다.


✈️ 좋은 URI 설계란?

회원 목록 조회와 회원 등록을 위한 API를 만들어본다고 가정해보자. 회원 목록 조회와 회원 등록은 같은 리소스를 필요로 한다. 그렇다면 회원 목록 조회를 위한 URI와 회원 등록을 위한 URI를 따로 만들 필요가 있을까?

좋은 URI를 평가하는 기준은 리소스를 얼마나 잘 식별하느냐 이다.
이를 위해서는 ‘리소스’ (회원)와 ‘행위’ (조회, 등록, 삭제, 변경 등..)를 구분해야 한다. 이때 ‘행위’ 의 역할을 대신해주는 것이 바로 HTTP Method 이다.


✈️ HTTP Method

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


GET

요청

ch4 3

  • 리소스 조회
  • 서버에 전달하고 싶은 데이터(ex.정렬 조건)는 query(쿼리 파라미터, 쿼리 스트링)을 통해 전달
  • 메시지 바디를 사용해 데이터를 전달할 수 있지만 지원하지 않는 곳이 많아 권장하지 않음. (바디를 이용해 전달하려는 건 쿼리문이 워낙 지저분해서 그러나?)


응답

ch4 4

  • 바디를 통해 쿼리 결과 응답


POST

1. 요청

ch4 5

  • 요청 데이터는 메시지 바디를 통해 서버로 전달
  • 요청 데이터 처리 (처리의 의미? 뒤에서 설명)
  • 전달된 데이터는 주로 신규 리소스 등록, 프로세스 처리에 사용


2. 신규 리소스 생성

ch4 6


3. 응답

ch4 7


요청 데이터 ‘처리’의 의미

말 그대로 리소스 URI에 POST 요청이 들어오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해줘야 한다 는 뜻이다. 즉, POST는 어떤 작업도 할 수 있는 무적의 메소드다. ‘바디를 이용해 리소스 조회를 하고싶다’ 하는 애매한 상황에서는 그냥 POST를 쓰면 된다. (사실 POST로도 조회를 할 수 있지만 GET은 캐시를 할 수 있다는 강점이 있다. 캐시에 대해서는 마지막 챕터에서 다룬다.)


PUT

ch4 8

  • 리소스 대체(덮어 쓰기)
    • 리소스 존재o -> 대체
    • 리소스 존재x -> 생성
  • 클라이언트가 리소스 URI를 지정해줘야 한다. (다음 단원에서 자세히 다룬다.)

PUT 주의사항

PUT의 경우 리소스를 완전히 갈아 치운다. 만약 중요한 정보가 빠진 데이터를 PUT으로 요청하고 처리하게 되면 DB가 망가질 수 있다. 따라서 PUT 요청을 처리하기 전에는 반드시 결함이 없는지 확인을 해야 한다.


PATCH

ch4 9

  • 리소스의 원하는 부분만 변경


DELETE

ch4 10

  • 리소스 제거


기타 Method

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


CORS (Cross-Origin Resource Sharing) - 교차 출처 리소스 공유

‘CORS가 뭐지?’ 하고 찾아봤다가 내용이 꽤 흥미로워서 간단히 정리하려고 한다. CORS란 클라이언트가 자신이 요청 메시지를 보낸 서버의 출처와 자신이 받은 응답 메시지의 출처를 비교해보고 만약 출처가 다르면 응답 메시지를 파기해버리는 정책이다. (사실 서버에 접근 권한이 있는 출처가 여러 개 있을 수 있어서 ‘출처가 다르다’라는 의미는 SOP 정책에 위반된다는 의미이다.)
왜 이런 과정을 거칠까? 잘 생각해보면 출처가 다른 두 개의 애플리케이션이 아무 제약 없이 소통하는 것은 꽤 위험한 환경이다. 당장 브라우저의 개발자 도구만 열어도 리소스며, 통신 정보며, 심지어 소스 코드까지 볼 수 있는 사이트가 있다. 만약 개발자가 악의를 가진다면 소스 코드를 쓱 구경한 후 애플리케이션과 통신하는 것처럼 사용자를 속여 중요 정보를 탈취할 수도 있을 것이다. 뿐만 아니라 사용자도 모르는 사이 쿠키 정보를 빼돌려 중요한 요청을 위조할 수도 있다. (Cross-Site Request Forgery (CSRF) - 사이트간 요청 위조) 더 자세한 내용은 내가 참고한 블로그에서 확인해보면 좋을 것이다.

정말 정리가 잘 된 블로그 ➡️ CORS는 왜 이렇게 우리를 힘들게 하는걸까?


✈️ HTTP Method 속성

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

안전
GET과 같이 호출해도 리소스를 변경하지 않는 method를 의미한다.


멱등
f(f(x)) = f(x) 한 번 호출하던, 두 번 호출하던, 백 번 호출하던 결과가 같은 method를 의미한다.

  • POST: 멱등X (ex.중복 결제 발생)
  • Idempotent method의 경우 요청했는데 응답이 없으면 다시 요청을 하는 자동 복구 메커니즘을 사용할 수 있다.
  • 주의) 재요청 하는 중간에 다른 곳에서 리소스를 변경할 수 있다.
    • user1) GET
    • user2) PUT (리소스 변경)
    • user1) GET


캐시 가능
캐시란 간단히 말해 반복적으로 사용해야하는 데이터를 매 번 서버에 요청해 다운받지 말고 클라이언트가 가지고 있다가 재사용 한다는 뜻이다. (맞나..?) 아무튼 캐시에 대한 이야기는 뒤에서 자세히 다룬다.

  • 응답 결과를 리소스를 캐시해서 사용해도 되는가?
  • 스펙 상 캐시 가능 : GET, HEAD, POST, PATCH
  • 사실 GET, HEAD 정도만 캐시로 사용 (POST, PATCH는 본문 내용까지 캐시 키를 지정해야 하는데 구현이 쉽지 않음)


ch4 1


맨 위로 이동하기

Network 카테고리 내 다른 글 보러가기

댓글 남기기

최근 글 10 개 :)