HTTP 메서드
URI 은 무슨 기준으로 설계를 할까?
어떤 것이 좋은 uri 설계일까?
uri를 통해 리소스를 식별할 수 있어야 한다
- 리소스의 의미
- 회원을 등록하고 수정하고 조회한다면 회원이라는 개념 자체가 리소스이다
- 리소스를 어떻게 식별?
- 등록 수정 조회 등 동사는 모두 배제하고 회원이라는 리소스만 식별하면 되기에
- 회원이라는 리소스를 uri에 매핑
→ 리소스와 해당 리소스의 행위를 분리해야한다
ex)
회원 목록 조회 /memebers
회원 조회 /memebers/{id}
회원 등록 /memebers/{id}
회원 수정 /memebers/{id}
회원 삭제 /memebers/{id}➕ 리소스를 representation이라는 말로도 사용 가능
Http 메서드 종류
주요 메서드
- get : 리소스 조회
- post : 요청 데이터 처리
- put : 리소스 대체, 해당 리소스가 없으면 생성
- patch : 리소스 부분 변경
- delete : 리소스 삭제
기타메서드
- head : get과 동일한데 메시지 바디를 제외하고 헤더까지만 전송
- options : 대상 리소스에 대한 통신 기능 옵션을 설명 (cors에서 사용) → 참고정도로만
- connect : 대상 자원으로 식별되는 서버에 대한 터널 설정 → 거의 사용x
- trace : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트 수행 → 거의 사용x
Get
역할: 리소스를 조회
get같은 경우에는 요청할 때 데이터를 전송하는 경우가 많지 않다 하지만 검색을 요청하는 경우에는 필요한 검색 데이터를 전송해야 할 때가 있는데 파라미터를 통해 넘기는 경우가 대부분이다.
즉 get 메시지 바디를 사용하는 경우가 거의 없다 물론 get 요청일 때도 메시지 바디에서 데이터를 전송할 수 있지만 get 요청인데 바디를 파싱하는 서버가 많지 않다
ex)
서버로 부터 /members/100 url로 get 요청을 보낸다
서버는 http 메시지를 확인해보니까 /member/100의 get으로 요청이 왔고 여기에 해당하는 데이터를 보내야하구나라고 인지한다 그러면 그에 맞는 데이터를 만든 다음 서버에서 응답 데이터를 만들어서 보낸다( 응답 메시지를 보낸다)
Post
post는 메시지 바디를 통해 서버로 요청 데이터를 전달하고 요청 데이터를 처리하는 역할을 한다 post를 데이터를 등록한다고 인지하는 사람도 있는데 post 메서드는 데이터를 처리하는 역할을 하고 전달 받은 데이터가 주로 신규 리소스 등록이나 프로세스 처리에 사용된다
💡 데이터를 어떻게 처리한다는 뜻일까?post로 전달받은 데이터는 신규 주문을 생성한다던지 댓글달기를 한다던지 주문에 사용한다던지 많은 예시들이 있지만 데이터를 어떻게 처리할지는 리소스마다 다르고 따로 정해야한다 → 정해진 것이 없다
데이터를 받으면 내부적으로 어떻게 이 데이터를 처리할거라고( 사용할거라고) 약속을 한다
- post 언제 사용
- 새 리소스 생성
- 요청 데이터 처리
- 다른 메서드로 처리하기 힘든 경우
- ex) patch를 지원안하거나 (put은 전체 대체이기에 같이 사용 못함) JSON으로 조회 데이터 넘겨야하는데 get 메서드에 바디 메시지에 데이터를 첨부해야해서 get 메서드 대신 post를 사용하는 경우
컨트롤 URI
우리가 요청 데이터처리가 단순 변경을 넘어 프로세스의 상태가 변경되는 경우가 있다
예를 들어 결제 완료나 배달 시작과 배달완료는 행위로 주문이라는 리소스로 식별할 수 있다
그렇다면 /orders/{orderId}와 같이 주문이라는 리소스를 통해 url을 설계할 수 있다 하지만 결제 완료 배달 시작 배달 완료 같은 경우에는 모두 행위를 post 메서드를 사용한다. 즉 http 메서드를 통해 행위가 구분이 안된다
결제 완료를 하여 /orders/{orderId} url로 post 요청을 보낸다면 이에 맞는 프로세스 처리와
배달 시작을 하여 /orders/{orderId} url로 post 요청을 보낸다면 이에 맞는 프로세스 처리와
배달 완료를 하여 /orders/{orderId} url로 post 요청을 보낸다면 이에 맞는 프로세스 처리가 각각 다를 것이다 하지만 같은 url 같은 메서드를 통해 보내게 된다
이러한 문제를 해결하기 위해서 /orders/{orderId}/start-delivery와 같이 컨트롤 uri를 설계할 수 있다 ( 실무에서는 간단히 해결되는 경우가 많이 없어 컨트롤 uri를 자주 사용한다)
보통 동사를 많이 사용한다
💡 **컨트롤 uri는 문서(단일개념), 컬렉션, 스토어 개념으로 최대한 해결을 해보고 안된다면 컨트롤 uri를 통해 해결을 한다 ( 무작정 컨트롤 uri를 사용하는 것은 좋지 않음)**ex) post 메서드 예시
클라이언트가 서버에게 post 메서드로 http 메시지를 보낸다 이때 데이터가 포함되어 있다
신규 리소스 식별자를 생성해서 신규 리소스를 등록하고 응답 데이터를 보낸다
201로 보낼때 location도 보통 보내는데 location은 자원이 신규 생성된 경로를 뜻한다
Put Patch Delete
put
- put은 리소스를 대체하는 것이다 ( 덮어쓴다)
- 리소스가 없으면 생성한다
이때 중요한 것은 클라이언트가 리소스를 식별한다. 즉 클라이언트가 리소스 위치를 알고 URI를 지정한다
이게 post와의 차이점인데 위 예시를 보면 post는 데이터 생성을 위해 데이터를 /memebers로 전송하면 이 데이터가 100번에 만들어질지 200번에 만들어질지 모른다. 하지만 put은 클라이언트가 /memebes/100에 이 데이터로 대체할 것이라는 것을 정해야한다 구체적인 리소스 경로를 아는 것이다!
ex)
- 리소스가 있는 경우
membersid가 100인 회원으 데이터는 young과 20이다 하지만 put으로 인해 old와 50으로 대체되어 버렸다 만약 데이터가 존재하지 않으면 새로 old 50이라는 회원으로 생성될 것이다.
{”username”: “young” , “age’:20}인 데이터를 {”age”:50}으로 대체한다면 {”username”:”young”}이 되는 것이 아닌 {”age”:50}이 된다
Patch
- 리소스를 부분변경한다
위 같은 예시에 put이 아닌 patch 메서드를 사용하면 age만 50으로 변경한다 username은 그대로 young이다!
Delete
- 리소스 제거
HTTP 메서드의 속성
안전
http 메서드가 안전하다는 것은 변경이 일어나지 않는다는 것을 의미한다
http 주요 메서드 중 get을 제외한 모든 메서드는 데이터 변경이 발생한다
→ 안전하지 않다
멱등
http 메서드에서 멱등이라는 의미는 한 번 호출하든 두 번 호출하든 결과가 똑같다는 것을 의미한다.
get : 한 번 조회하든 , 두 번 조회하든 결과가 똑같다
put : 결과를 대체하기에 put을 여러번 호출해도 보내는 데이터의 값으로 대체하는 것이기에 결과는 똑같다
delete : 결과를 삭제한다 요청을 여러번해도 삭제된 결과는 같다
post : 멱등이 아니다 post는 데이터를 처리하는 역할을 한다 만약 데이터 처리가 결제라면 결제를 두 번 할 수도 있는 것이고 그러면 몇번 호출하냐에 따라 결과가 달라진다
💡 이런 멱등성을 어떻게 활용할까?자동 복구 매커니즘에 활용하기 위해서다!
예를 들어 delete메서드를 사용했는데 서버에 응답이 없다면 delete 메서드를 통해 데이터가 잘 삭제되었는지 안되었는지 모를 수도 있다 그러면 다시 delete 요청을 한다 delete 메서드는 멱등이기에 여러번 호출해도 결과가 바뀌지 않는다.
이런 자동 복구 매커니즘을 post가 아닌 이상 사용 가능하다
( 단 호출이 아닌 외부 요인으로 리소스가 변경되는것으로 인해 멱등이 아니다라고 고려하지 않는다)
