[rest] 컨벤션으로 어떤 REST PUT / POST / DELETE 호출을 반환해야합니까?

Program / 글쓴이

  1. “REST 이데올로기”에 따르면 PUT / POST / DELETE 요청에 대한 응답 본문에는 무엇이 있어야합니까?

  2. 리턴 코드는 어떻습니까? 가 HTTP_OK충분?

  3. 그러한 규칙이있는 이유는 무엇입니까?

POST / PUT의 차이점을 설명하는 좋은 게시물을 찾았습니다. POST vs PUT
그러나 여전히 내 질문에 대답하지 않습니다.

답변

뒤집기를 용서하지만 HTTP를 통해 REST를 수행하는 경우 RFC7231 은 GET, PUT, POST 및 DELETE에서 예상되는 동작을 정확하게 설명합니다.

업데이트 (Jul 3 ’14) :
HTTP 사양은 의도적으로 POST 또는 DELETE에서 반환되는 내용을 정의하지 않습니다. 사양은 정의해야 할 내용 만 정의합니다. 나머지는 선택할 수있는 구현 자에게 맡겨져 있습니다.

답변

전체적으로이 규칙은“웹 페이지를 제공하는 것처럼 생각합니다”.

PUT의 경우 즉시 GET을 수행 한 경우와 동일한 뷰를 반환합니다. 200이 될 것입니다 (물론 렌더링이 성공한다고 가정). POST의 경우 생성 된 리소스로 리디렉션합니다 (생성 작업을 수행한다고 가정하고 그렇지 않은 경우 결과 만 반환). 성공적인 작성을위한 코드는 201이며, 실제로는 300 범위에없는 리디렉션의 유일한 HTTP 코드입니다.

나는 DELETE가 무엇을 반환해야하는지에 대해 결코 행복하지 않았다.

답변

리소스 생성은 일반적으로 POST에 매핑되며 새 리소스의 위치를 ​​반환해야합니다. 예를 들어 Rails 스캐 폴드에서 CREATE는 새로 생성 된 리소스에 대해 SHOW로 리디렉션합니다. 동일한 접근 방식이 업데이트 (PUT)에 적합 할 수 있지만 이는 일반적이지 않습니다. 업데이트는 성공을 나타내기만하면됩니다. 삭제는 성공 여부 만 표시하면됩니다. 리디렉션하려는 경우 리소스 목록을 반환하는 것이 가장 적합합니다.

성공은 HTTP_OK로 표시 될 수 있습니다 (예).

위에서 언급 한 유일한 단단하고 빠른 규칙은 CREATE가 새 리소스의 위치를 ​​반환해야한다는 것입니다. 그것은 나에게 쉬운 일인 것 같습니다. 클라이언트가 새 항목에 액세스 할 수 있어야한다는 것이 합리적입니다.

답변

RFC7231은 중요하지 않으며 비어있을 수 있습니다.

프로젝트에서 json api 표준 기반 솔루션을 구현하는 방법 :

post / put : get에서와 같이 객체 속성을 출력합니다 (필드 필터 / 상대 관계는 동일하게 적용됨)

delete : 데이터에는 null 만 포함됩니다 (손실 된 객체를 나타냄)

표준 삭제 상태 : 200

답변

업데이트 및 삭제를 위해 HTTP 상태 코드 에서 Alfonso Tienda 응답이 마음에 드
십니까?

다음은 몇 가지 팁입니다.

지우다

  • 200 (응답에 추가 데이터를 보내려는 경우) 또는 204 (권장).

  • 202 삭제 된 작업이 아직 커밋되지 않았습니다.

  • 삭제할 항목이 없는 경우 204 또는 404를 사용하십시오 (삭제 조작은 ent 등원, 이미 삭제 된 항목 삭제가 성공적으로 완료 되었으므로 204 를 리턴 할 수 있지만 dem 등성이 반드시 동일한 응답을 의미하지는 않습니다)

다른 오류 :

  • 400 잘못된 요청 (잘못된 구문 또는 잘못된 쿼리는 이상 하지만 가능합니다).
  • 401 무단 인증 실패
  • 403 금지 : 승인 실패 또는 유효하지 않은 응용 프로그램 ID.
  • 405 허용되지 않음 . 확실한.
  • 409 리소스 충돌 은 복잡한 시스템에서 가능합니다.
  • 그리고, 501 , 502 오류가 발생하는 경우이다.

놓다

컬렉션의 요소를 업데이트하는 경우

  • 위의 DELETE와 동일한 이유로 200/204 .
  • 작업이 아직 커밋되지 않은 경우 202

참조 된 요소가 존재하지 않습니다 :

  • PUT은 201 이 될 수 있습니다 (요소로 인해 요소를 작성한 경우)

  • 404 PUT을 통해 요소를 작성하지 않으려는 경우.

  • 400 잘못된 요청 (DELETE의 경우보다 잘못된 구문 또는 잘못된 쿼리).

  • 401 무단

  • 403 금지 : 인증 실패 또는 유효하지 않은 응용 프로그램 ID.

  • 405 허용되지 않음 . 확실한.

  • 409 자원 충돌 은 DELETE와 같이 복잡한 시스템에서 가능합니다.

  • 422 처리 할 수없는 엔티티 “잘못된 요청”(예 : 잘못된 형식의 XML / JSON)과 유효하지 않은 필드 값을 구별하는 데 도움이됩니다.

  • 그리고, 501 , 502 오류가 발생하는 경우이다.

답변