[HTTP] http 메서드(GET, POST, PUT, PATCH, DELETE)

HTTP API를 만들어보자!!

요구사항 - 아래 기능을 동작하는 회원 정보 관리 API를 만들어라

• 회원 목록조회
• 회원 조회
• 회원 등록
• 회원 수정
• 회원 삭제

API URI(Uniform Resource Identifier) 설계

URI설계에 있어 가장 중요한 것은 리소스를 식별하는것이다.

• 리소스의 의미는뭘까? 회원을 등록하고 수정하고 조회하는것이 리소스가아니다!!  
• 회예) 미네랄을캐라 -> 미네랄(리소스) // 회원이라는 개념 자체가 리소스이다.
• 리소스 식별? -> 회원이라는 리소스만 식별 -> 회원 리소스를 URI맵핑

리소스만을 식별해서 API URI를 설계한 모습이다. URI계층 구조를 활용한다.

회원 목록조회 /members

회원 조회  /members/{id} -> 어떻게 구분?

회원 등록 /members/{id}  -> 어떻게 구분?

회원 수정 /members{id}

회원 삭제  /members/{id}

URI는 리소스만 식별한다.

리소스와 해당 리소스를 대상으로 하는 행위를 분리해야됨 

리소스 : 회원 / 행위: 조회,등록,삭제,변경

 

그렇다면 행위(메소드)는 어떻게 구분할까?

우리는 URI로 리소스만 식별하면, 행위( 조회,등록,수정,삭제) 구분은 ->HTTP 메소드가 해준다!!

 

---

HTTP 메소드 

GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, CONNECT, TRACE 등등 

---

GET : 리소스 조회

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

• 서버에 전달하고 싶은 데이터는 쿼리 파라미터, 쿼리스트링을 통해서 전달
• GET에서 메세지 바디를 전달할수도있지만, 지원하지 않는 서버가 많아서 권장하지않음

---

POST : 요청 데이터 처리, 주로 등록에 사용

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

 

• 요청 데이터 처리 - 클라이언트 : "데이터 처리 요청" -> 서버: "데이터 처리"
• 클라이언트의 메세지 바디를 통해 서버로 요청 데이터 전달, 서버는 요청 데이터를 처리(메세지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행)
• 주로 신규리소스 등록 혹은 프로세스 상태변경과 같은 처리에 사용됨.

응답데이터를 보통 201인경우 Location PATH를(/members/100) 보내준다 + 등록된 자원

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

---

POST가 쓰이는 예

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

정리하자면, 리소스 URI에 POST요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야한다. -> 정해진것이없다.

그래서 POST요청으로 메시지 전달을 하기전에 미리 클라와 서버사이에 어떤 처리를할건지 서로 약속을 해둔다

 

1. 새 리소스 생성(등록)

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

2. 요청 데이터 처리 (프로세스 처리단계)

• 프로세스의 상태변경에도 쓰인다. (post의 결과로 새로운리소스가 생성되지않더라도 서버에서 큰변화가 일어날게 할때 사용)
• 예) 주문에서 결제완료->배달시작->배달완료 처럼 단순히 값 변경을 넘어 프로세스 과정자체 프로세스 상태를 변경시킬때 사용되는 것이 POST이다.
• POST의 결과로 새로운 리소스가 생성되지 않을 수도 있다.
• 예) 다음과 같이 리소스만으로 uri설계해야하는데 어쩔수없이 리소스만으로 설계가안되는 경우(orders/{orders}/start-delivery)도있다 -> 이런경우 POST를 사용하여 컨트롤 uri로 설계한다. POST/orders/{orders}/start-delivery

3. 다른 메소드로 처리하기 애매한 경우(어쩔 수 없는경우)

• json으로 메세지 바디에 조회데이터를 넘겨야하는데, get메소드를 지원하지 않는경우
• 애매하면 다 POST사용

정리하자면 조회는 최대한 get을 이용 ,
새 리소스 생성, 요청데이터 처리, 프로세스가 변경, 혹은 어쩔수없는경우 post사용

 

---

PUT : 리소스를 대체, 해당 리소스가 없으면 생성

 

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

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

}

• 쉽게 이야기해서 덮어버리는거다, 완전히 대체한다, 리소스가 있으면 대체하고 없으면 새로 생성한다.
• 중요! 클라이언트가 리소스를 식별한다(즉, 클라이언트가 구체적인 리소스의 전체 위치를 알고 uri을 지정한다.) ->post와의 차이점
• PUT은 members/100에다가 집어넣을거야 라면서 미리 지정할수있음
• POST는 members/로 보내고 어디에 집어넣어질지 모른다 서버가 결정함
• 리소스를 완전히 대체하기 때문에 부분변경이 어려움 이는 patch를 사용해야함     만약 username: old, age는 지정x put요청할경우.. 이미 username, age가 전부 있는경우에도 age는 삭제되고 username만 put된다.

 

 

 

---

PATCH : 리소스 부분 변경

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

{
"age": 50

}

• put은 전체를 덮어쓰기 되므로 부분적인 요소변경이 어렵다, patch는 부분적인 요소만 특정해서 변경하는것이 가능하다.
• patch가 지원이 안되는 서버에 경우, post를 쓰세요 post는 무적

 

---

DELETE : 리소스삭제

DELETE /members/100 HTTP/
1.1 Host: localhost:8080

• 해당경로 즉 member/100리소스 자체가 제거됨

---

HEAD : GET과 동일(요청)하지만, start-line, header까지만 반환  body (X)

OPTIONS,

CONNECT,

TRACE, 등 있음

---

HTTP메소드의 속성

안전 (safe)

• 호출해도 리소스를 변경하지 않는다. get뺴곤 다 안전하지않음,  바꾸는것들은 다 안전하지않음
• 계속해서 호출하면, 로그가 쌓여 장애가 발생할수있지않나요? -> 안전은 그거까지 고려하지않음 리소스를 바꾸냐 안바꾸냐정도만 고려

 

멱등 (Idempotent)

• 한번 호출하든 두 번 호출하든 100번 호출하는 결과가 똑같음
• 결과물이 같으면 멱등이다
• get,patch,put,delete는 멱등하다, 그러나 post는 멱등하지않음 두번호출하면 같은 결제가 중복해서 발생하기때문에->중복결제, 중복주문 등등 
• 자동복구 메커니즘에 쓰인다.  자동복구 메커니즘?? : 서버가 응답을 못주는 상황일때, 같은 클라이언트가 동일한 요청을 다시한다(재요청) ->어차피 결과는 같으니 문제없는 요청 good
• 재요청 중간에 다른곳에서 리소스를 변경해버리면 동일한 결과가 안나올수도있다. 멱등하지않다. -> 그러나 멱등은 외부요인으로 중간에 리소스가 변경되는것까지는 고려하지않는다. 동일한 사용자가 동일하게 요청했을때 멱등한것만 고려, 외부요인은 서버가 체크해줘야할 부분

 

캐시가능 (Casheable)

• 응답결과 리소스를 캐시해서 사용(응답결과 리소스를 내 pc에 저장하고 있을 수 있냐 없냐)해도되는가?
• GET,HEAD,POST,PATCH는 캐시가능하다.
• 그러나 GET,HEAD정도만 캐시 사용.  POST,PATCH는 캐시 키로 고려해야되는데 구현이 쉽지않음.

 

 

 

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

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