POST 메소드 결과에 관한 논의

[Dae-Hwa]

들어가기에 앞서, 저희 클라이언트 개발자분들의 요구사항과 별개로 HTTP 표준준수에 대한 논의입니다.

POST의 결과로 어떤 데이터가 생성됐는지 어떤 형태로든 클라이언트로 보내줘야한다고 생각합니다.

이유는 예전 회의에서도 말했듯이, POST의 결과로 생성되는 ID는 클라이언트에서 가지고 있는 것이 아니기때문에, 저희가 제공해주지 않으면 클라이언트에서는 알 수 없습니다.

가장 쉬운 방법으로는 새로 생성된 리소스의 ID를 제공하는 것입니다. 일단 논의가 되지 않은 상황에서 일단은 저도 이렇게 구현해놓긴 했습니다.

하지만, HTTP 표준 문서에는 Location 헤더 필드에 표현하거나 Request URI를 제공해야 한다고 되어 있습니다.

The primary resource created by the request is identified by either a Location header field in the response or, if no Location field is received, by the effective request URI.
https://datatracker.ietf.org/doc/html/rfc7231#section-6.3.2

If one or more resources has been created on the origin server as a result of successfully processing a POST request, the origin server SHOULD send a 201 (Created) response containing a Location header
field that provides an identifier for the primary resource created (Section 7.1.2) and a representation that describes the status of the request while referring to the new resource(s).
https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.3

저희도 이에 맞춰서 응답 헤더에 생성된 아이템을 어디에서 조회할 수 있는지 넣어주는게 어떨까 하는 생각입니다.

[Dae-Hwa]

추가로 Post 메소드의 응답으로 201 Create가 와야 한다고 합니다.
저희 API에 대부분 204로 되어있는데 이 부분은 수정하는게 좋을 것 같습니다!

[sallyjellyy]

Post 메소드에 대한 응답코드로 201이 와야 한다는 건 처음 알았네요! 공유 감사합니다. 그럼 내일 회의때 이 부분 같이 수정하면 될까요?

[janeljs]

예시

Location: /users/1

[Dae-Hwa]

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Location

[Dae-Hwa]

Location을 넣기 힘든 이유

1. 반드시 리소스에 대한 GET 메소드가 존재해야 한다.

• POST 메소드를 만들기 전에 GET을 항상 먼저 만들어야 한다.

2. 테스트에서 Location 헤더만 비교할 경우

• 사전 정의 된 테스트 데이터의 개수에 따라 결과가 달라진다.
  • 예상되는 id가 2인데, 테스트 데이터가 추가되어서 id가 3으로 나올 경우 수정이 필요하다
  • 이 경우는 body로 id를 반환해도 동일한 문제

Location을 사용하거나 Body에서 id만 반환하면 생기는 문제

#172

id를 entityManager를 통해 직접 조회 하기가 까다롭다.
엔티티 클래스를 수정하거나, fetch join을 하는 테스트 쿼리가 추가로 필요해진다.