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.
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.