문제

내 휴식 API는 JSON을 반환합니다.

나는 현재 Mime 유형으로 텍스트/평원을 반환하고 있지만 재미 있다고 느낍니다. 돌아와야할까요? application/x-javascript 아니면 다른 유형?

두 번째 질문은 오류 조건에 대한 HTTP 상태 코드와 관련이 있습니다. 내 REST API가 오류 상태를 반환하는 경우 JSON으로 돌아오고 있습니다.

{ result: "fail", errorcode: 1024, errormesg: "That sucked. Try again!" }

HTTP 상태 코드가 남아있는 경우 200 OK?

도움이 되었습니까?

해결책

The JSON spec suggests application/json, and that seems to be supported by the IETF and IANA registry.

On the second question, I think if the message handling fails in some way you should return a structured and standard error response as a JSON message; only if there is a failure to deliver the message to the backend handler for some reason should you consider an HTTP error code.

Update 2014-06-27: The days where clients (browsers) only worked with a 200 response are long past and the prevailing advice for RESTful APIs is to use HTTP response codes appropriate for the response, 2xx for successful responses (e.g. 201 Created for PUT; 204 No Content for DELETE) and 4xx and 5xx for all error conditions, including those from the API itself.

다른 팁

I prefer to reply with both an HTTP error status and application specific payload.

No, you shouldn't return 200 in an error condition.

It's ok to repeat the status code, or to include a more detailed error code in the response payload.

The proper Content-type to return is application/json, according to RFC 4627, which also registers the MIME type IANA (and indeed, it shows up on IANA's page). Of course, if you were to write a client, you would want to be more liberal in what you accept, and also accept others such as text/json and text/x-json.

Now, if there is an error you should not return HTTP 200, that's fundamentally non-RESTful. I know that sometimes there's not an exact match for your error, but choose the closest 4XX (client's fault) or 5XX (server's fault) errors in RFC 2616 Sections 10.4-10.5, and be more precise in the JSON.

If by "REST API" you mean that you want to follow a REST architecture then the media type to use is determined by the functionality you want to expose through the REST API. Do you want to be able to create new objects? Query a list of objects? Edit an object? If so, then a good RESTful media type to use might be vnd.collection+json because it defines a hypertext linked interface to manipulate a collection of json objects.

Note: A RESTful API could use the media type application/json, but this media type doesn't have a hypertext linked RESTful interface, so it would be an end point in the state change.

It's also completely acceptable to follow a web API architecture, where HTTP RPC calls return application/json objects, and other HTTP RPC calls manipulate those objects, and there is no hypertext link interface for using and navigating the state changes. But this isn't REST.

I like this description of REST (from the creator of REST):

REST APIS must be hypertext driven

In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period.

Also, from the discussion of that post is this example of a RESTful application: Lost Boys's Spam-E REST Application

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top