JSON 웹 서비스에서 오류 상태를 반환하는 기존 방식이 있습니까?

JSON 웹 서비스에서 오류 상태를 반환하는 기존 방식이 있습니까?

저는.jQuery AJAX 게시물을 수신하는 NET .ashx 핸들러는 웹 서비스 요청을 타사 서비스로 포맷하고 결과를 소비합니다.성공하면 관련 정보를 가진 익명 개체를 인스턴스화하고 JSON 응답 문자열을 포맷합니다.

웹 서비스 오류가 발생하면 다음 작업을 수행합니다.

context.Response.StatusCode = (int)HttpStatusCode.InternalServerError;
context.Response.StatusDescription = wsResult.ErrorCode;

따라서 상태 코드와 설명 모두 jQuery AJAX 오류 콜백에 쉽게 액세스할 수 있습니다. 그러나 이를 구현하는 방식은 상당히 자의적입니다.

책을 좀 읽어 보았지만 다음 질문에 대한 결정적인 답을 찾을 수가 없습니다.오류 상태를 JSON 기반의 AJAX 호출로 반환하는 보편적 협약(또는 심지어 사양)이 승인되어 있으며, 이를 통해 소비자는 무엇을 기대해야 하는지 알 수 있습니다. 아니면 다른 함수 호출에 대한 반환 유형만큼 임의적입니까?

그렇다면, 이것이 AJAX 호출자에게 오류 상태를 반환하는 완벽하게 허용 가능한 방법입니까, 아니면 JSON 오류 응답을 포맷하는 "적절한" 방법이 있습니까?

다른 사람들이 말했듯이, 보편적인 관습은 없습니다.REST "공동체"는 아직도 이와 같은 문제에서 어느 정도의 합의점을 찾는 과정에 있습니다 - 합의점을 찾을 수 없을지도 모릅니다.몇 가지 예를 들어보겠습니다.

상태코드

기본적으로 ServiceStack.널리 사용되는 C#인 NET REST 라이브러리 웹 서비스 프레임워크는 개체(또는 빈 응답)를 상태 코드와 함께 반환합니다(예:

201 Created

또는:

200 OK

유효성 검사 오류의 경우(예:ArgumentException), 예를 들어 다음을 수행할 수 있습니다.

400 Bad Request

그리고 상황이 달라지기 시작하는 첫 번째 지점이 이미 여기에 있습니다.어떤 사람들은.400유효성 검사 오류와 같은 것에 대한 상태 코드 - 다른 것들은 그렇지 않습니다.400요청 형식 자체에서 형식이 잘못된 구문을 나타냅니다.

어떤 사람들은 더 좋아합니다.422 Unprocessable Entity검증 오류의 경우 HTTP 프로토콜에 대한 WebDAV 확장이지만 기술적으로는 여전히 완벽하게 허용됩니다.

다른 사람들은 HTTP 프로토콜에서 사용되지 않는 오류 상태 코드 중 하나를 간단히 가져가야 한다고 생각합니다.461. 트위터는 (다른 사람들 중) 그것을 했습니다.420 Enhance Your Calm(표면적으로) 허용 가능한 (그리고 권장되는) 상태 코드가 있는 경우에도 불구하고, 고객에게 현재 요금 제한 상태임을 알립니다.429 Too Many Requests이미 그런 목적으로

그 외에 다 철학의 문제입니다.

에 관해서는500 Internal Server Error, 동일한 적용 - 어떤 사람들은 모든 종류의 오류 응답에 대해 완벽하게 괜찮다고 생각하고, 다른 사람들은 다음과 같이 생각합니다.5xx오류는 예외(예: 예외 오류)에 대해서만 반환되어야 합니다.오류가 정말 예외적인 경우에는 서버에 대해 너무 많은 것을 드러낼 수 있는 실제 예외 정보를 전달하고 싶지 않은 경우가 대부분입니다.

JSON 결과에서 무엇(있는 경우)을 반환해야 합니까?똑같은 거...

대답

200 OK예를 들어, 오류가 발생하지 않은 경우 리소스 삭제 요청에 응답하기에 충분할 수 있습니다.마찬가지로.404 Not Found삭제할 엔터티를 찾을 수 없어 요청한 삭제를 수행할 수 없다고 클라이언트에게 알리기에 충분합니다.그 외의 경우에는 그 이상이 필요할 수도 있습니다.

응답 헤더에 필요한 정보를 가능한 한 많이 포함해야 한다고 생각하는 사람도 있습니다. 종종 헤더만 있는 빈 응답이 있습니다.예를 들어, 생성 시 반환201 Created생성된 엔티티의 ID(Resource URI로)를 입력합니다.Content-Location 없습니다 응답 내용이 필요 없습니다.

저는 개인적으로 공개 API를 만들고 있다면 내용이 다소 중복이 되더라도 적절한 헤더와 내용을 모두 반납하는 것이 좋다고 생각합니다.예를 들어:

HTTP/1.1 404 Not found
Content-Type: application/json; charset=utf-8
...

{
   'Success': false,
   'Message': 'The user Mr. Gone wasn't found.'
}

(실제로는 포함하지 않습니다.Success속성이지만 API를 설계할 때의 내 마음의 틀에 따라 그렇게 하고 싶을 수도 있습니다.

DEBUG 모드에서 실행할 때 내부 서비스 호출의 문자열 표현도 포함합니다.'Request': 'GetUser { id: 5 }', 타임스탬프와 스택 트레이스가 있습니다.하지만 그건 모두 편리함의 문제입니다.단순히 다음을 기반으로 적절한 사용자 친화적 오류 메시지로 클라이언트를 코드화하는 것은 충분히 쉽습니다.404 Not found 일부 유효성 검사)는 더 할 수 그러나 일부 다른 오류(예: 유효성 검사)는 더 많은 컨텍스트가 필요할 수 있습니다.예를 들어,

HTTP/1.1 422 Validation Error
Content-Type: application/json; charset=utf-8
...

{
   'Success': false,
   'Message': 'The request had validation errors.',
   'Errors':
   {
       'UserName': 'The user name must be provided.',
       'Email': 'The email address is already in use.'
   }
}

서비스 스택.NET은 기본적으로 이와 같은 작업을 수행하지만 속성과 내용이 약간 다릅니다.마이크로소프트의 자체 웹 API 프레임워크도 비슷한 기능을 합니다.관련 질문에 연결된 Jsend 사양은 또 다른 변형입니다.

뭐 이런 거.

간단히 말해서, 아니요, 적어도 아직 보편적인 관습은 없습니다.많은 사람들이 (나보다 더 많은 생각을 하고) 작업을 하고 있습니다.하지만 여전히, 절대 없을 수도 있습니다.그리고 당신의 방법은 완벽하게 받아들일만 합니다.

(네, 이것은 매우 길었습니다. 대부분 제가 한동안 같은 종류의 "보편적인 컨벤션"을 찾아다녔기 때문입니다.)

상태 코드에 대한 자세한 내용은 훌륭한 기사입니다(여기에 인용하기에는 너무 깁니다).

아니요, 이게 좋을 수도 있지만 주요 기준은 하나도 없습니다.다음을 포함할 수 있는 표준을 만들고 있는 경우 유용할 수 있습니다.success그리고.details, 정확히 어떻게 쓰느냐에 따라 달라지죠일관성을 위해 최소한 모든 자체 코드에 걸쳐 표준을 구현하는 것이 큰 장점이라고 생각합니다. 예를 들어 http://ricardocovo.com/2012/03/08/asp-net-mvc-using-json-standard-responses-for-your-ajax-calls/ .

귀하의 요구에 부합한다면 귀하의 답변은 전적으로 받아들일 수 있습니다.API로 작업할 경우, 부울을 원할 수도 있지만 응답 코드와 설명을 포함하는 '표준'으로 오류 응답을 볼 수 있습니다.success편리하게 사용할 수 있도록

나의 2센트:

우선 응답으로 다시 보내주시는 상태 코드가 가장 좋은 오류 지시자이고 4xx, 5xx 범위의 많은 옵션을 제공한다고 말씀드리고 싶습니다... (티포트에서 커피를 좀 HttpGET하려고 할 때도 418:D를 사용할 수 있습니다.

200이 아닌 것은 일종의 오류이며 http 상태 코드는 어떤 경우에 사용되어야 하는지 잘 문서화되어 있으므로 더 이상의 오류 메시지는 필요하지 않습니다(오류 설명은 상태 코드에 의해 암시됨).브라우저는 요청을 수행하는 브라우저이며, 오류 메시지는 신경 쓰지 않고 상태 코드만 사용합니다.

추가적인 오류 메시지가 발생하면 발생 가능한 해킹 시도에 너무 많은 정보를 제공할 수도 있습니다.제 말은 403 Forbidden을 반납하는 것은 그 자체로 충분한 정보이기 때문에 "No permitted, please'1234"라는 메시지도 반납하면 안 된다는 것입니다. :)

Google JSON Style Guide는 데이터 x 또는 오류 개체를 사용합니다...

API 간에 일관된 인터페이스를 유지하기 위해서는 아래에 설명된 구조를 따라야 합니다.이 구조는 JSON을 이용한 요청과 응답 모두에 적용됩니다.
. . .
JSON 개체에는 몇 가지 최상위 속성이 있으며 그 다음에 데이터 개체 또는 오류 개체가 있지만 둘 다는 아닙니다.

예제...

{
  "apiVersion": "2.0",
  "error": {
    "code": 404,
    "message": "File Not Found",
    "errors": [{
      "domain": "Calendar",
      "reason": "ResourceNotFoundException",
      "message": "File Not Found
    }]
  }
}

저는 일반적으로 서버측 시스템의 이름, 구조, 내용을 관행적으로 채택하고 있습니다.

이 관행은 프론트엔드 개발자가 이미 이해한 어휘를 사용하여 백엔드 개발자와 소통할 수 있도록 보장하며, 프론트엔드 개발자와 디자이너가 새로운 개념을 발명할 때 백엔드 개발자가 새로운 형식을 구현하는 작업을 수행하는 표준/판례를 설정하지 않습니다(오류는 오류이므로 "유형"에 대해 머리를 싸매지 말자)." 그리고 "meta"는 주어진 오류의 속성일 뿐입니다.)

예를 들어 오류 세부 정보를 "JSON 클라이언트"에 반환하고 서비스 엔드포인트가 C#을 사용하여 구현되는 경우 다음과 같은 JSON 문서를 반환하고 싶습니다.

{ 
  "Message": "An error has occurred.", 
  "ExceptionMessage": "Index was outside the bounds of the array.", 
  "ExceptionType": "System.IndexOutOfRangeException", 
  "StackTrace": "   at WebApiTest.TestController.Post(Uri uri) in c:\\Temp\\WebApiTest\\WebApiTest\\TestController.cs:line 18\r\n   at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>c__DisplayClassf.<GetExecutor>b__9(Object instance, Object[] methodParameters)\r\n   at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.Execute(Object instance, Object[] arguments)\r\n   at System.Threading.Tasks.TaskHelpers.RunSynchronously[TResult](Func`1 func, CancellationToken cancellationToken)",
}

물론 수용된 답변을 앵무새처럼 따라 하지 않기 위해, 저는 특히 여러분이 이런 저런 방법을 잘 모르는 폴리글롯(또는 완전히 새로운 프로그래머)이라면, 통일성에 있어서의 가치가 엄청난다는 것을 전하고 싶을 뿐입니다.

지금은 문제가 되지 않지만, 2년, 3년, 5년 정도의 유지보수 기간이 지나면 관리를 시작할 수도 있고, 유사한 규정 준수 관행을 수용하는 다른 개발자들을 만나면서 장기적으로 "재교육"해야 하는 자신을 발견할 수도 있고, 팀 내에서 (필요하지 않을 때는) 여전히 새로운 포맷을 개발하려고 노력하는 유일한 남성일 수도 있습니다.

참고: 분명히 말씀드리지만, 고객에게 예외 사항을 연속적으로 제공하는 것은 아닙니다. 그러나 디버깅, 보안 프라이빗 클라우드 또는 중요한 데이터/IP가 없는 경우 등 많은 시나리오에서 완벽하게 유효한 옵션일 수도 있습니다.

언급URL : https://stackoverflow.com/questions/17293934/is-there-a-conventional-way-of-returning-error-statuses-from-json-web-services