HTTP | 섹션 4. HTTP 메서드

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

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

🟦 섹션 4. HTTP 메서드

⬛ 1. HTTP API 를 만들어보자

◼️ API URI 설계의 분리

• 리스소 (대상) : 회원 - 명사
• 행위 : 조회/등록/수정/삭제 - 동사

API URI 설계를 할 때 ‘리소스(대상)’ 과 해당 리소스를 대상으로 하는 ‘행위’는 분리해야 한다.

회원이라는 리소스만 식별해두고, 회원 리소스를 URI에 매핑하면 된다.

◼️ 요구사항 → [잘못된 설계 vs 재설계]

전반적인 설명

• 행위의 대상이 ‘리소스’가 된다.
• URI는 ‘계층 구조’를 사용해야 하며, URI는 오직 리소스만 식별해야 한다.
• 리소스를 식별해놓으면 HTTP 메소드로 그 행위를 대신 한다.

 

◼️ 요구사항에 따른 API URI 설계 방법

1) 요구사항을 본다.

2) 리소스와 행위를 분리한다.

(URI는 계층 구조를 활용, URI는 오직 리소스만 식별한다)

3) 설계를 바탕으로 리소스를 식별했다면 이제 HTTP 메소드로 행위를 하면 된다.

---

HTTP 메소드 : 클라이언트가 서버에 무언가 요청을 할 때 기대하는 ‘행동’이다.

🟩 HTTP 메소드의 종류 (주요 메소드)

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

🟩 HTTP 메소드의 종류 (기타 메소드)

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

---

⬛ 2. HTTP 메서드 - GET, POST

◼️ GET | 단순 리소스 조회

1) 클라이언트는 요청 데이터를 ‘query(쿼리 파라미터, 쿼리 스트링)’을 통해 서버에 전달

메시지 바디 사용하여 데이터 전달 가능하지만, 지원하지 않는 곳이 많아서 권장X

2) 서버는 DB에서 단순 조회 결과를 응답 메시지에 담아 클라이언트에 전달

---

클라이언트가 /members/100 GET 메시지로 요청을 하면,

서버는 회원 정보 DB에서 /members/100 번 User의 정보를 조회한 뒤, 응답 메시지를 만들어서 다시 클라이언트에게 보낸다.

GET의 처리 예시

 

◼️ POST | 요청 데이터 처리

1) 클라이언트는 요청 데이터를 ‘메시지 바디’를 통해 서버에 전달

2) 서버는 요청 데이터를 처리한 뒤 그 결과를 응답 메시지에 담아 전달

서버는 메시지 바디를 통해 들어온 데이터를 처리하는 ‘모든 기능’을 수행한다.

주로 전달된 데이터로 ‘신규 리소스 등록’이나 ‘변경된 프로세스를 바꿀 때 사용한다’

---

클라이언트가 /members POST 메시지로 요청을 하면,

서버에는 그 데이터를 내부적으로 어떻게 쓸지 약속이 되어있는 상태여서, 그에 따른 구체적인 행위를 할 것이다. 예시의 경우, ‘신규 생성 처리’로 약속된 상태이다. 그래서 서버는 신규로 /members/에 100번 사용자로 신규 리소스 식별자를 생성한 뒤, 신규로 자원이 생성된 경로를 응답 메시지로 보낸다.

POST 처리 예시

 

◼️ 위 그림에서, POST 요청 데이터를 어떻게 처리한다는 뜻일까 ?

• 스펙: POST 메소드는 대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청합니다.

//POST는 아래와 같은 기능에 사용된다.

1) HTML 양식에 입력된 필드와 같은 데이터 블록을 ‘데이터 처리 프로세스’에 제공

• HTML 폼에 입력한 정보로 회원 가입, 주문 등에서 사용

2) 게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사 기사 그룹에 메시지 게시

• 게시판 글쓰기, 댓글 달기
• 게시판에 글 쓰고 submit 누르면 POST로 글이 서버로 전달되고, 그 서버가 게시판에 글을 저장한다.

3) 서버가 아직 식별하지 않은 새 리소스 생성

• 신규 주문을 생성하거나 신규 회원 생성할 때

4) 기존 자원에 데이터 추가

• 한 문서 끝에 내용 추가하기

---

◼️ POST 하는 일 정리

1) 신규 리소스 생성(등록)

• 서버가 아직 식별하지 않은 새 리소스 생성

2) 요청 데이터 처리

• 단순히 데이터를 생성, 변경하는 것을 넘어서 프로세스를 처리해야 할 경우
• ex. 주문에서 결제 완료 → 배달 시작 → 배달 완료 처럼 단순한 값 변경을 넘어 프로세스의 상태가 변경되는 경우
• POST의 결과로 새로운 리소스가 생성되지 않을 수도 있음
• ex. POST/orders/{id}/start-delivery {컨트롤 URI}

기본적으로 리소스로 최대한 URI를 설계하되, 실무에서 어쩔 수 없는 부분들은 컨트롤 URI로 설계를 한다. 이럴 때 POST를 많이 쓴다.

3) 다른 메소드로 처리하기 애매한 경우

• ex. JSON으로 조회 데이터를 넘겨야 하는데, GET 메소드 사용하기 어려운 경우
• 애매하면 POST 사용한다.

---

⬛ 3. HTTP 메서드 - PUT, PATCH, DELETE

◼️ PUT | [덮어버림] 있으면 리소스를 대체, 없으면 리소스 생성

• 리소스가 있으면 대체하고, 없으면 생성한다.
• POST와 차이 : PUT은 클라이언트가 구체적인 리소스의 전체 위치를 알고 URI를 정확히 지정해서 서버에게 전달한다.

POST/members HTTP/1.1 이런 식으로 보낸 것과 달리 

PUT /members/100 HTTP/1.1  이라고 명확히 구체적인 URI 리소스 구체적으로 지정

[PUT - 리소스가 있는 경우]

• 클라이언트가 /members/100 으로 리소스를 지정해서 데이터를 서버에게 보내면
• 서버도 DB상에서 조회해봤는데 /members/100 이 있다 !
• 그러면 서버는 클라이언트가 보낸 리소스로 해당 리소스를 대체(덮어버린다)

[PUT - 리소스가 없는 경우]

• 클라이언트가 members/100 리소스 지정해서 데이터를 서버에게 보냈는데
• 서버에서 조회해봐도 해당 리소스가 없다면
• 그러면 서버는 클라이언트가 보낸 리소스를 신규 리소스로 생성시킨다.

[PUT 주의 사항] : 리소스를 완전히 대체한다.

PUT의 덮어버리는 문

• 클라이언트가 /members/100 를 PUT으로 보낼 때 username은 없고, age만 지정해서 보낸다면
• 서버는 기존에 있던 데이터를 날리고 클라이언트가 보낸 리소스로 완전히 대체하기 때문에 보내진 age는 업데이트하는 반면 username 자체는 날려버린다.
• PUT 이 기존 리소스를 새로운 리소스로 완전히 대체하기 때문!
• 이렇게 되면 리소스 수정이 어렵다.

→ 이렇게 부분 변경을 하고 싶으면 PUT 사용없이 어떻게 처리해야 할까 ?
→ PATCH가 해결해준다.

 

◼️ PATCH | 리소스 부분 변경

• 클라이언트가 /members/100 을 PATCH로 보낼 때 데이터에 username없이 age만 지정해서 보내면
• 서버는 username은 그대로 두고, 보내온 age값만 변경시킨다.

◼️ DELETE | 리소스 삭제

• 클라이언트가 /membres/100을 DELETE로 보내면,
• 서버는 해당 리소스를 삭제시킨다.

---

⬛ 4. HTTP 메서드의 속성

HTTP 속

◼️ 안전(Safe Methods)

뜻 : 호출해도 리소스 상태에 변경이 일어나지 않는다.

• GET은 단순 조회만 하기 때문에 안전하다. 여러번 호출해도 변경 일어나지 않아서 ‘안전’하다.
• POST, PUT, PATCH, DELETE는 안전하지 않다.

Q. 그래도 GET을 계속 호출해서 로그같은 게 쌓여 장애가 발생한다면요 ?

A. 안전은 해당 리소스의 상태만 고려한다. 그 외의 장애까지 고려하지 않는다.

◼️ 멱등 (Idempotent Methods)

뜻 : 한 번 호출하든, 두 번 호출하든, 100번 호출하든 결과가 똑같다.

[멱등 메소드]

• GET : 한번 조회하든, 두 번 조회하든 어쨋든 ‘동일한 결과’가 조회된다.
• PUT : 결과를 완전히 덮어버린다. 따라서 같은 요청 여러 번 해도 덮어버린 최종 결과는 ‘동일하다’
• DELETE : 결과를 삭제한다. 같은 삭제 요청 여러 번 해도 삭제된 결과는 ‘동일하다.
• POST : 멱등 아니다. 두 번 호출 시, 중복된 결과에 대하여, 완전히 새로운 리소스로 구별이 된다.

[멱등의 활용]

• 자동 복구 매커니즘으로 활용할 수 있다.
• 왜냐면, 멱등하기 때문에 똑같은 요청을 두 번 해도 괜찮다.
• 클라이언트가 자동 DELETE를 호출했는데, 서버에서 잘 되고있는건지 응답이 없다.
• 클라이언트가 다시 DELETE를 재시도 해도 멱등한다.

[멱등은 외부 요인 고려 X]

• 외부 요인으로 중간에 리소스가 변경되는 것까지 고려하지 않는다.
• 똑같은 클라이언트가 동일한 요청을 했을 때만 멱등한다.
• 예시의 경우, 다른 클라이언트의 영향으로 데이터가 중간에 바뀌었는데, 기존 클라이언트가 조회했어도 멱등한 것으로 본다. (해당 처리에 따른 동일 결과 반환 한 것으로 본다)
• 즉, 동일한 요청을 동일한 클라이언트만 요청했을 때 결과가 같다면 멱등한 것.
• 즉, 멱등은 동시성 문제까지 고려하지 않는다.

◼️ 캐시사능(Cacheable Methods)

• 웹 브라우저에 용량 큰 이미지 한 번 요청하면, 이후에 또 해당 이미지를 요청할 필요는 없다.
• 똑같은 이미지를 서버에서 다운로드 받으면 오래 걸린다.
• 따라서 로컬 PC에 웹 브라우저 저장을 해두고 이것을 [캐시]라고 한다.
• 캐시는 GET, HEAD, POST, PATCH 모두 가능하지만,
• GET, HEAD 정도만 캐시로 사용한다.
• POST, PATCH는 캐시하려면 복잡해서 구현 쉽지 않다.