ansaurus

Question

Answer 1

A:

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.

Darrel Miller 2010-05-28 02:18:19

I agree that its unlikely that they can't handle text plan, but in the rest of the API they can get away with using just the single Accept type they want - i.e. in lots of my testing I use restclient and just set Accept to application/json. In that case I really have to return the wrapped boolean JSON don't I?

Andrew Patterson 2010-05-28 02:26:20

Yeah, as per `http://tools.ietf.org/html/rfc2616#section-14.1` if your client doesn't say it supports text/plain then you should not send it.

Darrel Miller 2010-05-28 03:46:02

Answer 2

A:

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?

manuel aldana 2010-05-30 10:02:57

Manuel, thanks for your thoughtful comments. Imagine we have a resource 'john', and another resource 'bob'. Both of these have properties such as name, address, date of birth, list of friends etc.So they are both 'resource' like and could be fetched with a GETin a restful architecture.I however want to ask a boolean question about the relationship between these two resources. The actual relationship is simple (i.e. can I reach one person via friends from the other person), but obviously involves some computation at the server end.So I want to ask HTTP GET /bob/isrelated/john

Andrew Patterson 2010-05-31 01:06:50

I can think of two possibilities: 1) Do a GET on /bob/friends and check whether john is an item inside the response. Or go step further and do GET /bob/friends/john, if you get a 404 then there is no friendship between them, 200 otherwise. 2) Include this info directly to the resource: GET /bob, then search inside <human><name>bob</name><friends><friend><human><name>john... . If john is part of the response there is a relation, if not otherwise. From Rest perspective I wouldn't directly think in server-computation terms (it is api implementation detail).

manuel aldana 2010-05-31 20:26:01

Yes, I agree that if my 'relationships' were expressible that simply I would include them in the resource. What I mean by it involving computation on the server is that a resource might have hundreds of thousands of related resources (it's the complete transitive closure of a complex network). So whether the relationship exists relies on data that cannot be sent to the client - it must be computed by the server

Andrew Patterson 2010-06-01 08:31:22

ansaurus

tags:

views:

answers:

best practice for boolean REST results

related questions