업데이트 및 삭제를위한 HTTP 상태 코드?

UPDATE( PUT) 및 DELETE(예 : 제품 업데이트)에 어떤 상태 코드를 설정해야 합니까?

A에 대한 PUT의 요청 : HTTP 200 또는 HTTP 204 을 의미한다 "리소스가 성공적으로 업데이트".

A에 대한 DELETE 요청 : HTTP 200 또는 HTTP 204 을 의미한다 "자원이 삭제". HTTP 202 도 리턴 될 수 있는데, 이는 서버가 명령을 수락하고 "자원이 삭제 표시"된 것을 의미합니다.

놓다

기존 리소스가 수정되면 요청 완료를 나타내는 200 (OK) 또는 204 (No Content) 응답 코드>를 보내야합니다.

지우다

응답에 상태를 설명하는 엔터티가 포함 된 경우 성공적인 응답은 200 (OK)이고, 조치가 아직 시행되지 않은 경우 202 (Accepted), 조치가 시행되었지만 응답이 포함되지 않은 경우 204 (No Content) 여야합니다. 실체.

출처 : W3.org : HTTP / 1.1 메소드 정의

HTTP 200 OK : 성공적인 HTTP 요청에 대한 표준 응답입니다. 실제 응답은 사용 된 요청 방법에 따라 다릅니다.

HTTP 204 컨텐츠 없음 : 서버가 요청을 성공적으로 처리했지만 컨텐츠를 리턴하지 않습니다.

출처 : HTTP 상태 코드 목록 : 2xx 성공

짧은 답변 : PUT과 DELETE 모두 200 (OK) 또는 204 (No Content)를 보내야합니다.

긴 대답 : 여기에 완전한 결정 다이어그램이 있습니다 (확대하려면 클릭하십시오).

출처 : https://github.com/for-GET/http-decision-diagram

다음은 몇 가지 팁입니다.

지우다

• 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 오류가 발생하는 경우이다.

RFC 2616은 사용할 상태 코드를 설명 합니다 .

그리고 아니요, 항상 200 은 아닙니다 .

200 및 204 외에도 205 (콘텐츠 재설정) 가 올바른 응답 일 수 있습니다.

서버는 요청을 이행했으며 사용자 에이전트는 요청을 보낸 문서보기를 재설정해야합니다. 예를 들어 입력이 제공된 형식을 지 웁니다.

DELETE 가 200 대 204를 반환해야하는지에 대한 질문이 있기 때문에 일부 사람들은 링크가있는 엔터티를 반환하도록 권장하므로 선호도가 200 입니다.

"대신에 204 (없음 콘텐츠) 반환하지의, API는 도움이 될 가서 장소를 제안한다 내가 제공 한 명백한 링크가 생각이 예." 'somewhere.com/container/'(마이너스 '자원') "- 클라이언트가 방금 리소스를 삭제 한 컨테이너입니다. 클라이언트가 더 많은 리소스를 삭제하려고하므로 유용한 링크가 될 것입니다. "

http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204-responses/

클라이언트가 204 응답을 받으면 포기하거나 API의 진입 점으로 이동하거나 방문한 이전 리소스로 돌아갈 수 있습니다. 두 가지 옵션 모두 특히 좋습니다.

개인적으로 나는 클라이언트 측에서 좋은 캐싱이 많은 이점을 가지기 때문에 204가 잘못되었다고 말하지 않을 것이다. 최선은 어느 쪽이든 일관되어야합니다.

여기 당신의 지식에 대해 알아야 할 상태 코드가 있습니다.

1XX 정보 응답

• 100 계속
• 101 스위칭 프로토콜
• 102 처리
• 103 초기 힌트

2XX 성공

• 200 OK
• 201 만든
• 202 수락
• 203 비 권한 정보
• 204 내용 없음
• 205 콘텐츠 재설정
• 206 콘텐츠
• 207 다중 상태
• 208 이미보고
• 226 IM 사용

3XX 리디렉션

• 300 객관식
• 301 영구적으로 이동
• 302 발견
• 303 다른 참조
• 304 수정되지 않음
• 305 프록시 사용
• 306 스위치 프록시
• 307 임시 리디렉션
• 308 영구적 인 리디렉션

4XX 클라이언트 오류

• 400 나쁜 요청
• 401 무단
• 402 지불 필요
• 403 금지
• 404 찾을 수 없음
• 405 메소드가 허용되지 않습니다
• 406 허용되지 않음
• 407 프록시 인증 필요
• 408 요청 시간 초과
• 409 갈등
• 410 사라지다
• 411 길이 필요
• 412 전제 조건 실패
• 413 페이로드가 너무 큼
• 414 URI가 너무 깁니다
• 415 지원되지 않는 미디어 유형
• 416 범위가 만족스럽지 않습니다
• 417 기대 실패
• 418 나는 주전자입니다
• 420 메소드 실패
• 421 잘못된 요청
• 422 처리 불가능한 개체
• 423 잠겨
• 424 실패한 종속성
• 426 업그레이드 필요
• 428 전제 조건
• 429 너무 많은 요청
• 431 요청 헤더 필드가 너무 큼
• 451 법적 사유로 사용할 수 없음

5XX 서버 오류

• 500 내부 서버 오류
• 501 미구현
• 502 나쁜 게이트웨이
• 503 서비스를 이용할 수 없음
• 504 게이트웨이 시간 초과
• 505 Http 버전이 지원되지 않습니다
• 506 변형도 협상
• 507 저장 공간이 부족합니다
• 508 루프 감지
• 510 확장되지 않음
• 511 네트워크 인증 필요

2014 년 6 월 RFC7231은 RFC2616을 폐기합니다. HTTP를 통해 REST를 수행하는 경우 RFC7231 은 GET, PUT, POST 및 DELETE에서 예상되는 동작을 정확하게 설명합니다.

자원이 수정되면 응답 코드는 200 ( "OK") 이어야합니다 . URI를 자원으로 변경하는 방식으로 자원 상태가 변경되면 (예 : 사용자 계정의 이름이 변경됨) 응답 코드는 301 ( "영구적으로 이동 됨") 이며 Location 헤더는 새 URI를 제공해야합니다.

개체가 삭제되면 응답 코드 는 200 ( "OK")이어야합니다.

자세한 내용은 아래 링크를 참조하십시오- 휴식 상태 코드