"REST 이데올로기"에 따르면 PUT/POST/DELETE 요청에 대한 응답 본문에는 무엇이 있어야합니까?대회에서 REST PUT/POST/DELETE 호출이 반환해야하는 것은 무엇입니까?
반환 코드는 어떻게됩니까? HTTP_OK이면 충분합니까?
해당 규칙이있는 이유는 무엇입니까? POST vs PUT 를하지만 여전히 내 질문에 대답하지 않습니다
나는 POST/PUT의 차이를 설명하는 좋은 게시물을 발견했습니다.
flippancy를 용서하지만 HTTP를 통해 REST를 수행하는 경우 RFC7231은 GET, PUT, POST 및 DELETE에서 예상되는 동작을 정확히 설명합니다.
전체적으로 규칙은 "웹 페이지 만 전달하는 것 같아요"입니다.
PUT의 경우 바로 GET을 수행하면 얻을 수있는 것과 동일한 뷰를 반환합니다. 그 결과는 200 (물론, 렌더링은 물론 성공한다고 가정)이 될 것입니다. POST의 경우 생성 된 리소스로 리디렉션을 수행합니다 (생성 작업을 수행 중이라고 가정하고 그렇지 않은 경우 결과 만 반환). 성공적인 작성을위한 코드는 201이며, 실제로는 300 범위에없는 리디렉션의 유일한 HTTP 코드입니다.
DELETE이 반환해야하는 것에 대해 만족해 본 적이 없습니다 (이 경우 코드는 현재 HTTP 204와 빈 몸체를 생성합니다).
결과 페이지에서 새로 고침하면 요청이 다시 실행되므로 'PUT'요청이 반환되면 다음 페이지가 나쁜 것처럼 보입니다. 대신 나에게 동기식 요청을 처리한다고 가정 할 때 리디렉션을하는 것이 좋습니다. – lobati
@lobati 여러 개의 동일한 PUT 요청을 보내는 것이 동일한 PUT 요청 중 하나만 보내는 것과 정확히 같은 결과를 가져야한다는 사실을 기억하는 것이 중요하다고 생각합니다. 아마도 당신이 제기하는 이슈는 위의 상황에서 덜 중요 할 것입니다. – Iain
@Iain 정말로 아닙니다. 문제는 나중에 다른 사람이 레코드를 업데이트하면 다른 PUT 요청을 보내 데이터를 되돌릴 수 없게하려는 것입니다. 예를 들어, 두 사람이 동일한 페이지를 참조하는 경우 한 사람이 업데이트를 한 다음 다른 사람이 업데이트를 작성합니다. 첫 번째 사람이 결과를보기 위해 새로 고치면 두 번째 사람이 만들기 전에 다시 되돌아 가게됩니다. 그들의 변화. – lobati
자원 작성은 일반적으로 POST에 맵핑되며 새 자원의 위치를 리턴해야합니다. 예를 들어 Rails 스캐 폴드에서 CREATE는 새로 생성 된 리소스에 대한 SHOW로 리다이렉트 할 것이다. 동일한 접근법이 업데이트 (PUT)에 대해 의미가있을 수 있지만 관례는 적습니다. 업데이트는 성공을 나타낼 필요가 있습니다. 아마도 삭제는 성공을 나타낼 필요가있을뿐입니다. 리디렉션하려는 경우 리소스 목록을 반환하는 것이 가장 적합합니다.
성공 여부는 HTTP_OK로 지정할 수 있습니다.
내가 위에서 말한 유일하고 까다로운 규칙은 CREATE가 새 리소스의 위치를 반환해야한다는 것입니다. 그것은 나에게 생각할 필요가없는 것처럼 보인다. 클라이언트가 새 항목에 액세스 할 수 있어야합니다.
실제로 PUT과 POST가 섞여 있습니다. POST는 생성에 사용되고 PUT은 업데이트 (및 생성)에 사용됩니다. PUT은 멱등수 (idempotent)이어야하며 POST는 그렇지 않다는 점에 유의하는 것도 가치가 있습니다. – Stevie
네 말이 맞아. 나는 그들을 바꿨다. –
그래, 나는이 사실을 놓쳤다. 고맙습니다!이것은 각 http "메소드"에 대한 몇 가지 새로운 의미를 "발명"하고 SQL 작업에 매핑하는 것보다 분명히 논리적 인 것처럼 보입니다. – tuxSlayer
@tuxslayer 나는 당신이 내가 단지 snarky가 되려고 애쓰는 것을 생각하지 않아서 다행이다. 많은 사람들이 REST가 HTTP 메소드의 추가 요구 사항을 추가한다고 생각하는 것 같습니다. 그러나 그렇지 않습니다. 추가 제약 조건이 있지만 HTTP 메서드의 동작에 실제로 영향을 미치지는 않습니다. RFC2616은 확실히 따라야 할 가이드입니다. –
나는 링크를 주셔서 감사합니다. :) 그것은 내가 멈추고 내가 사용하고있는 도구에 대해 생각하게했다. 귀하의 게시물 및 RFC를 읽은 후, 나는 RFC의 나머지 부분을 참조하는 자신을 발견했습니다. 이 프로세스는 먼저 HTTP 프로세스로, 나머지 프로세스는 두 번째로 생각할 수있었습니다. 매우 감사. –