4. HTTP 메서드

본 포스팅은 우아한 형제들, 김영한 님의 '모든 개발자를 위한 HTTP 웹 기본 지식' 강의를 수강 후 정리한 글입니다.

 

 

 

요구사항

ex) 회원 정보 관리 API를 만들어라

• 회원 목록 조회 / read-member-list
• 회원 조회 / read-member-by-id
• 회원 등록 / create-member
• 회원 수정 / update-member
• 회원 삭제 / delete-member

 

1. 우선 API URI 설계 (URL 설계)

-> URI 설계의 중요한 점은 리소스 식별

 

2. 그렇다면 리소스는 무엇인가?

-> 회원을 등록하고 수정하고 조회하는 행위를 리소스소 보지 않는다.

-> ex) 회원을 등록하라 ≠ 리소스.  회원 = 리소스

 

3. '회원' 이 곧 리소스다.

-> 회원 정보 관리 시스템에 존재하는 수많은 개별적인 '회원'들이 리소스

-> 회원 리소스를 URI에 매핑

 

4. 회원 리소스를 URI에 식별해야 하므로, 아래처럼 작성해야한다.

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

-> 문제: 어떻게 구별하지?.? (다 같은 꼴이니)

 

5. URI는 리소스만 식별하기에, 리소스를 대상으로 하는 행위를 분리해야한다.

-> 리소스: 명사(회원) / 행위: 동사(조회, 등록, 삭제, 변경)

 

6. 행위는 곧 메서드이며, 이는 HTTP message의 시작라인에 기재 되어있다.

 

7. HTTP 메서드 종류

 

주요 메서드

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

기타 메서드

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

8. GET 메서드 :  서버로부터 정보를 조회하기 위해 설계된 메서드

-> 리소스 조회 역할(행위)

-> 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 서버도 많기 때문에 권장하지 않음.

-> 즉, 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)로 전달 (아래 그림에서, message body가 없음을 알 수 있다)

this is start line of HTTP

 

9. GET 메서드 동작 메커니즘

 

10. POST 메서드 : 리소스를 생성/변경하기 위해 설계된 메서드

-> 요청 데이터 처리

-> GET 메서드는 (메시지 바디를 사용하지 않고) 원하는 데이터를 그저 서버 사이드에서 가져올 뿐이다.

-> POST 메서드는 메시지 바디를 통해 서버로 요청 데이터를 전달한다.

 

11. POST 메서드 (신규 데이터를 생성할 때)

-> json 형식으로 username: 'young', age: 20 이라는 데이터를 서버에 등록시키고 싶을 때

-> (예를 들어, django form문에서 간단하게 이름과 나이를 적고 submit 누를 때의 메커니즘이라 생각하자)

-> 201 Created 응답 -> Location을 만들어 낸다 -> 성공적으로 서버에 데이터 등록(생성)이 됐음을 응답메시지로 보낸 것

 

12. POST 메서드 정리

1. 새 리소스 등록(생성) -> 서버가 아직 식별하지 않은 새 리소스 생성
2. 요청 데이터 처리 -> 단순 데이터 생성, 변경을 넘어 프로세스를 처리해야 하는 경우
3. 다른 메서드로 처리하기 애매한 경우 -> 조회 데이터를 넘겨야하는데 GET 메서드를 사용하기 어려운 경우

13. POST 요청 데이터 처리

-> ex) 주문에서 결제완료 - 배달 시작 -배달완료 처럼 단순 값 변경을 넘어 프로세스 상태가 변경되는 경우도 모두 POST 메서드로 처리

 

14. HTTP 메서드의 속성

• 안전 (safe methods)
• 멱등 (idempotent methods)
• 캐시 가능 (cacheable methods)

15. 안전

-> 호출해도 리소스는  변경되지 않는다. (GET, HEAD: 단순 조회이기 때문에)

Q: 연속 호출로 인한, 로그가 쌓이면 장애 발생하지 않나요?

A: 안전은 해당 리소스 자체만 고려한다. (로그가 쌓이는 것은 리소스와는 별개). 즉 장애 발생 X (안전하다!)

 

16. 멱등: 수학에서, 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미한다.

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

-> 즉, 재귀를 쳐도 자기 자신이 된다. 한번 호출하든, 100번 호출하든 결과는 같다. 이것이 멱등이다.

-> POST는 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있는데 이는 같은 결과가 달라지기 때문이다. f(f(x)) ≠ f(x) 

-> 반면 GET은 '멱등'을 유지하도록 설계되어 있다 => 동일한 요청을 반복하면 동일한 결과가 나와야한다.

 

17. 멱등의 활용

-> 자동 복구 메커니즘 : 서버가 TIMEOUT등 으로 정상 응답을 주지 못할 때, 클라이언트가 같은 요청을 계속해도 문제가 되지 않는가?

=> if yes: 멱등이다. => if no: 멱등이 아니다.

-> 서버가 정상 응답을 주지 못하는 상황에서 같은 요청이 계속 들어온다 => 같은 요청이 들어오기 때문에 같은 결과를 보여줘야 한다(멱등)

=> 그렇지 못하다면(다른 결과를 보여준다면) 멱등이 아니다

외부요인: PUT으로 인해 데이터가 변경된것이지, GET으로 인해 변경된 것이 아니기 때문

18. 캐시 가능

-> 응답 결과 리소스를 캐시해서 사용해도 되는가?

-> GET, HEAD, POST, PATCH 메서드는 캐시가능 -> 실제로는 GET, HEAD 정도만 캐시로 사용 (구현이 쉽지않아~)

 

-> GET은 불필요한 요청을 제한하기 위해 동일한 (GET) 요청에 대해 캐시 처리 될 수 있다.

-> js, css, 이미지 같은 정적 컨텐츠는 데이터양이 크고, 변경될 일이 적어 반복해서 동일한 요청을 보낼 필요가 없다.

-> 정적 컨텐츠를 요청하고 나면 브라우저에서는 요청을 캐시해두고, 동일한 요청이 발생할 때 서버로 요청을 보내지 않고 캐시된 데이터를 사용. 그래서 프론트엔드 개발을 하다보면 정적 컨텐츠가 캐시돼 컨텐츠를 변경해도 내용이 바뀌지 않는 경우가 종종 발생한다.

(브라우저의 캐시를 지워주면 다시 컨텐츠를 조회하기 위해 서버로 요청을 보내게 된다.)

 

 

 

 

 

 

참고

hongsii.github.io/2017/08/02/what-is-the-difference-get-and-post/