사용자에게 메시지를 보내는 애플리케이션이 있습니다. 게시 요청에서 특정 메시지를 수신해야하는 모든 사용자로 구성된 XML 문자열이 전송됩니다. 목록의 사용자가 존재하지 않는 경우 추가 평가를 위해 누락 된 사용자 목록을 클라이언트에 다시 제공합니다.
이제 요청이 수락되었지만 수행 할 수없는 일이 있다는 애플리케이션의 적절한 상태 코드가 무엇인지 스스로에게 묻고 있습니다.
목록에 누락 된 사용자를 포함 할 수 없으면 문제가 발생하지 않습니다. 그런 다음 전송 시도는 4xx 오류를 얻습니다. 그러나 이런 식으로 API를 구성하는 것은 의미가 없습니다. 반면에 오류 조건은 순전히 응용 프로그램에 특정한 것으로 간주 할 수 있습니다. 그러나 200을 보내는 것은 옳지 않다고 생각합니다. 그리고 오류 응답을 자세히 살펴볼 때 클라이언트에게 힌트를 제공하는 것이 좋습니다. 예 : 해당 사용자에게 계속해서 메시지를 보내는 것을 방지하기 위해
답변:
나는 매우 유사한 문제를 다루었습니다. 이 경우, 나는
207 다중 상태
이제 이것은 엄격한 HTTP가 아니며 WebDAV 확장의 일부이므로 클라이언트도 제어 할 수 없다면 좋지 않습니다. 그렇게하면 다음과 같이 할 수 있습니다.
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D='DAV:'>
<D:response>
<D:user>user-123</D:user>
<D:status>success</D:status>
</D:response>
<D:response>
<D:user>user-789</D:user>
<D:status>failure</D:status>
</D:response>
</D:multistatus>
그러나 이것은 HTTP 확장이며 클라이언트도 제어해야합니다.
나는 같은 문제가 있었고 결국 두 가지 다른 해결책을 사용했습니다.
202: Accepted, 요청이 정상임을 나타내지 만 모든 것이 실제로 제대로 진행된다는 보장은 없습니다.200응답에 정상 을 반환 하지만 응답 본문에 표시되지 않은 항목의 목록을 포함합니다.두 번째는 일반적으로 가장 잘 작동하지만 첫 번째는 게 으르거나 처리를 위해 대기열을 사용하는 경우에 좋습니다.
HyperText Transfer Protocol은 사물의 전송 측면을 다룹니다. 애플리케이션 수준 오류를 처리하기위한 오류 코드가 없습니다.
여기서 200을 반환하는 것이 옳은 일입니다. HTTP에 관한 한 요청이 제대로 수신되고 올바르게 처리되었으며 응답을 다시 보냅니다. 따라서 HTTP 수준에서는 모든 것이 정상입니다. http 위에서 실행되는 응용 프로그램과 관련된 모든 오류 또는 경고는 응답 내에 있어야합니다. 이렇게하면 특정 응답을 예상 한 방식으로 처리하지 못할 수있는 프록시 서버에서 발생할 수있는 몇 가지 불쾌한 문제도 방지 할 수 있습니다.