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

153

"REST 이데올로기"에 따르면 PUT / POST / DELETE 요청에 대한 응답 본문에는 무엇이 있어야합니까?
리턴 코드는 어떻습니까? 가 HTTP_OK충분?
그러한 규칙이있는 이유는 무엇입니까?

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

— 턱시도
소스

130

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

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

— 대럴 밀러
소스

9

@ tuxslayer 나는 당신이 내가 코를 막으려 고 노력하고 있다고 생각하지 않아서 기쁘다. 많은 사람들이 REST가 HTTP 메소드 위에 추가 요구 사항을 추가한다고 생각하는 것 같습니다. 그러나 그렇지 않습니다. 추가적인 제약이 있지만 HTTP 메소드의 동작에 실제로 영향을 미치지는 않습니다. RFC2616은 반드시 따라야 할 가이드입니다.

— Darrel Miller

4

나는 링크를 주셔서 감사합니다. :) 그것은 내가 사용하고있는 도구에 대해 멈추고 생각하게했습니다. 게시물과 RFC를 읽은 후 밤새 RFC를 언급하는 것을 발견했습니다. 프로세스를 HTTP 프로세스로, 나머지 프로세스를 먼저 생각하는 데 도움이되었습니다. 매우 감사.

— 페리 Tew

4

@PerryTew 지금 여기에 갈 수 tools.ietf.org/wg/httpbis 와 HTTP 사양의 현재 수정 된 버전을 참조하십시오. 즐겨!

— Darrel Miller

12

어쩌면 더 많은 수면이 필요하지만 OP가 RFC 내에서 요청한 정확한 정보를 찾지 못하는 것 같습니다. POST 또는 DELETE 응답을 위해 본문은 무엇이어야합니까?

— 캠 잭슨

9

음, 그것은 진흙만큼이나 분명합니다. 아마도 대답에 더 많은 정보가 도움이 될 것입니다. 특히, 그 링크가 죽었을 때.

— Doug Molineux

25

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

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

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

— 도널 펠로우
소스

1

갖는 PUT결과 페이지에서 새로 고침 이후, 다음 페이지의 나쁜 관행처럼 보인다 요청 복귀하는 것은 다시 실행 요청을하게됩니다. 대신 동기 요청을 처리한다고 가정하면 리디렉션을 수행하는 것이 좋습니다.

— lobati 2016 년

1

@lobati 여러 개의 동일한 PUT 요청을 보내는 것은 동일한 PUT 요청 중 하나만 보내는 것과 정확히 동일한 결과를 가져야한다는 점에 유의해야한다고 생각합니다. 아마도 위에서 제기 한 문제가 이제 덜 중요합니까?

— Iain

3

@Iain은 정말로 아니다. 문제는 나중에 다른 것이 레코드를 업데이트하는 경우 다른 PUT요청을 보내서 데이터를 되 돌리지 않게하는 것입니다. 예를 들어, 두 사람이 같은 페이지를 참조하는 경우 한 사람은 업데이트를하고 다른 사람은 업데이트를합니다. 첫 번째 사람이 새로 고침하여 결과를 볼 경우 실제로 두 번째 사람이 만들기 전에 물건을 되돌릴 수 있습니다. 그들의 변화.

— lobati

"웹 사이트와 같은 생각"은 완벽하므로 삭제는 다음 작업으로 응답 할 수 있습니다.이 작업은 리소스 삭제 이유에 대한 "이야기"에 따라 다릅니다. 이것은 적어도 에이전트를 일부 논리적 시작 위치로 되돌릴 수있는 링크 일 수도 있고 삭제의 영향 (순서 총계)을 표시하고 추가 링크를 포함하는 상태 자원으로의 리디렉션 일 수도 있습니다.

— Luke Puplett

3

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

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

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

— 제이콥 매티 슨
소스

2

실제로 PUT과 POST를 혼합했습니다. POST는 작성에 사용되고 PUT은 갱신 (및 작성)에 사용됩니다. PUT은 dem 등원이어야하지만 POST는 그렇지 않다는 점도 주목할 가치가있다.

— Stevie

dem 등원 명령은 여러 번 실행해도 제대로 작동합니다. 따라서 부정적인 부작용없이 동일한 "업데이트"를 적용하기 위해 동일한 PUT을 여러 번 수행 할 수 있어야합니다.

— Jacob Mattison

1

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

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

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

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

표준 삭제 상태 : 200

— 마리우스 그리
소스

0

업데이트 및 삭제를 위해 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 오류가 발생하는 경우이다.

— 리아 첸코 알렉산더
소스