HTTP 메서드 (GET, POST, PUT, PATCH, DELETE), 메서드 속성

 GET

리소스를 조회하는 역할을 한다. 서버에 전달하고 싶은 데이터는 query를 통해서 전달한다. (저번에 포스트 했던 글을 생각해보면 GET/search?q=hello&hl=ko HTTP/1.1 에서 GET과 HTTP 사이를 말한다.) 메시지 바디를 사용할 수도 있지만 최근 나온 스펙에서만 가능해서 권장하지 않고 query를 이용하는 것을 권장한다.

GET을 사용한 http 메시지 (왼쪽이 요청, 오른쪽이 응답 메시지)

 왼쪽 이미지(요청 메시지)는 GET을 사용하여 URI에 접근을 요청했다. 오른쪽 이미지(응답 메시지)에서 200으로 상태를

표시해주었고 OK로 상태 설명을 간단히 해주었다. 부가 정보가 있는 header를 보면 json 형식으로 길이 34의 메시지를 전달한다. 

 

 POST

클라이언트가 보내는 데이터를 처리하는 메서드이다. POST는 메시지 바디에 데이터를 담아서 서버에 요청한다. 이때 서버한테 하는 요청이 신규 리소스 등록, 프로세스 처리 등 여러가지가 될 수 있는데 이는 미리 POST가 들어오면 어떤 작업을 할지 정해둔다고 한다. 

POST를 사용한 http 메시지 (왼쪽이 요청, 오른쪽이 응답 메시지)

 위의 예시는 서버가  리소스 등록을 해준다. 요청 메시지를 보면 /members를 보냈다. 그 다음 응답 메시지의 Location을

보면 /members/100으로 나와있다. /members만 보내도 POST가 알아서 URI를 설정해 준다. POST에 대한 작업이 

원활하게 이루어져 있으면 보통 상태 코드 201과 함께 Created를 보낸다고 한다. (200 이어도 상관없음.) 그리고 201이면 Location 정보를 보내주는 것이 관례라고 한다.

 POST는 메시지를 내부에 담아서 하는 모든 것을 할 수 있다고 한다. 하지만 조회같은 처리는 GET 사용이 유리하다고 한다.

 요청 데이터를 처리할 때 단순 데이터 생성, 변경을 넘어 프로세스 처리도 가능하다고 한다. (안 해봐서 무슨 뜻인지 정확히 모르겠다. 실전 경험이 필요할 듯) 메시지를 담는 모든 것을 할 수 있는 POST는 JSON으로 조회 데이터를 넘겨야 하는 경우에도 사용 가능하다. 왜냐? JSON은 메시지 바디에 담아야 하는데 GET은 메시지 바디 사용 안 한다고 위에서 설명하였다. 

 애매하면 POST (라고 나와있다)

 

  PUT

 리소스를 대체 해준다. 그전에 중요한 것이 요청 메시지를 보낼 때 URI를 정확히 지정해야 한다. 구체적인 리소스를 알고 있어야 한다는 뜻이다. 위의 POST에서는 /members 까지만 보냈다. 하지만 PUT을 하려면 /members/100이라고 보내야 하는 것이다. 해당 위치에 리소스가 있으면 대체하고 없으면 생성한다. 대체할 때 원래 있던 데이터는 완전히 날려 버리고 새로 덮어쓴다. 

PUT 요청 메시지

 리소스가 존재하지않으면 신규 리소스를 생성한다. 존재하는 경우는 덮어쓴다. 존재하던 리소스에 만약에 성별에 관련한 데이터가 있었어도 데이터가 덮어쓰기 때문에 username, age 만 남는다.

 응답 메시지는 리소스가 존재하지 않았을 때 201 Created를 전송하고, 존재하였을 경우 200 OK 또는 204 No Content를 전송한다.

 

 PATCH, DELETE

PATCH는 리소스 부분을 변경해준다. 리소스의 필드 값을 수정해준다고 보면 된다. age 값이 50 이였는데 40으로 바꾸는 느낌. (근데 PATCH를 존재하지 않는 필드로 하면 어떻게 되는거지???) DELET는 말 그대로 리소스를 제거한다. 두 메서드 모두 요청 메시지에서 구체적인 URI를 작성해주어야 한다.

 

 추가로 http 메서드에 상태 줄과 헤더만 반환하는 HEAD, 대상 리로스에 대한 통신 가능 옵션을 설명해주는 OPTIONS등이 더 있다.

 HTTP 메서드 속성

 안전(Safe) - 호출해도 리소스를 변경하지 않는다. GET은 속성들을 변경하지 않고 조회만 해오기에 이에 해당한다.

 

 멱등(Idempotent) - 몇 번을 호출해도 결과 값이 똑같다. POST는 멱등하지 않다. (예제로 두 번 호출하면 같은 결제가 반복 발생할 수 있다고 나와있는 걸 보니 위에서 프로세스 처리도 가능하다고 나온 것과 연관이 있어 보인다.)

 멱등을 이용하여 자동 복구 메커니즘을 할 수 있다. 예를 들어 /members/100을 DELETE 하였다. 그런데 응답 메시지가 제대로 오지 않아서 진행이 된건지 알 수가 없다. 이때 멱등을 이용하여(몇번을 호출해도 결과 값이 같다.) 그냥 DELETE를 한번 더 진행할 수 있다~

 

캐시 가능(Casheable) - 이 부분은 캐시를 배우고 다시 정리해야 할 것 같다. 무슨 말인지 모르겠다

 

https://inf.run/QTy9

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