Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

best practice for boolean REST results

Tags:

I have a resource

  /system/resource

And I wish to ask the system a boolean question about the resource that can't be answered by processing on the client (i.e I can't just GET the resource and look through the actual resource data - it requires some processing on the backend using data not available to the client). eg

  /system/resource/related/otherresourcename

I want this is either return true or false. Does anyone have any best practice examples for this type of interaction?

Possibilities that come to my mind:

  • use of HTTP status code, no returned body (smells wrong)

  • return plain text string (True, False, 1, 0) - Not sure what string values are appropriate to use, and furthermore this seems to be ignoring the Accept media type and always returning plain text

  • come up with a boolean object for each of my support media types and return the appropriate type (a JSON document with a single boolean result, an XML document with a single boolean field). However this seems unwieldy.

I don't particularly want to get into a long discussion about the true meaning of a RESTful system etc - I have used the word REST in the title because it best expresses the general flavour of system I am designing (even if perhaps I am tending more towards RPC over the web rather than true REST). However, if someone has some thoughts on how a true RESTful system avoids this problem entirely I would be happy to hear them.

like image 477
Andrew Patterson Avatar asked May 28 '10 01:05

Andrew Patterson


People also ask

Why you shouldn't use booleans in REST APIs?

If not carefully considered, booleans can: Obstruct API Extensibility. Mask and obfuscate Domain Clarity. Hamper Code Readability and Maintainability.

What is a good practice that should be followed for a REST API?

REST API Best Practices: Prioritize Nouns over Verbs in URI Since REST API is mostly developed for resources like services, it is essential to use Nouns and not verbs. So it is better to use only Nouns to represent an entity in REST endpoint paths. This is because the HTTP request method already consists of verbs.


2 Answers

hmm, difficult to answer (your example is a bit too abstract for me).

Generally you can design such a boolean information as the resource-data or as dedicated resource. Example for the domain of orders, when you want to know whether the order is completed or not (boolean question). Beware this is simplified example (world of orders much more complex ;)

Design order state as data payload

HTTP call: HTTP GET /orders

Would give you back 200 OK with payload (json format): { id : "1" , completed : "true" }

Design order state as resource

HTTP call: HTTP GET or HEAD /orders/completed/1

Now to get your "boolean" answer you can check whether the HTTP response status was 404 or 200. 400 would tell the order is NOT completed yet, 200 would tell it is completed.

To help you more you have to be more specific, what in detail is your "boolean question"? what is the real resource and related-resource?

like image 177
manuel aldana Avatar answered Oct 18 '22 01:10

manuel aldana


I would think returning text/plain would be the cleanest option. As far as the accept header is concerned, if the client really can't handle text plain, then you could revert to Json, or Xml.
Personally, I would use the strings "true" and "false". Most client languages can parse those strings to their appropriate value.

like image 33
Darrel Miller Avatar answered Oct 18 '22 01:10

Darrel Miller