views:

296

answers:

5

Hi there,

I have a web service with some methods, they technically don't do much on the client.. i am calling it by jquery/ajax

What is the recommended return type, i would normally return JSON ... but in the case that it doens't return anything .. do i return a boolean? i.e. true = succesful ... and false = error ??

Any ideas?

A: 

You could go the SOAP route and return a status in XML.

This would be parse-able by almost anything.

Like:

<m:IsYourMethodSuccessful xmlns:m="Some-Namespace-URI”> 
    <return>true</return> 
</m:IsYourMethodSuccessful>

The benefit here is that you could return detailed exception information if, in the future, you decide that you need to add client-side feedback.

Or, since you are already parsing json:

{ success : true }

{ success : false, exception : { ... } }
John Gietzen
Why was this down-voted? Both the XML and the JSON methods make it an *extensible* way to return a status.
John Gietzen
yes i would like to know this too when i saw your reply i was thinking thats a good way to go..
mark smith
A: 

I would just return a boolean - simplest thing that could work.

Toby Hede
yes currently just returning a boolean ...is is returned as d.true or d.false ... using asp.net...
mark smith
+3  A: 

How about HTTP Status codes:

200 OK
500 Error
Tomalak
thanks for the answer,, technically the ajax has worked .. i get the error codes in my error from ajax... its if the procedure fails on the server .. so 500 wouldn't be correct would it ...as the HTTP has worked .. the method on the server failed..
mark smith
Look at it this way: You want the web server to do something, so you send a request. The server responds, telling you whether it worked or failed.
Tomalak
A: 

It depends a bit on the method. For updates and creates, I normally return the server id of the entity, and the time the create or update was made. This helps clients manage the state of entities locally, if they are storing them.

Chris Henry
+1  A: 

If it doesn't return anything you should use the HTTP status code:

204 No Content
The server successfully processed the request, but is not returning any content.

HTTP Status codes are fine for other uses as well but take care to use them only for HTTP status not application status.

For application status, you should consider using a standard JSON object (or SOAP or XML or whatever format you are using). This is also how Stack Overflow does it which you can verify by running an HTTP debugger on it:

{ "response": true, "data" : <data>, "message" : <message> }

The response property should ideally be true or false to keep the logic simple on the client. The message will usually typically be null unless an error occurs in which case it will contain the error message.

As far as HTTP status codes are concerned, they should be used only to indicate HTTP, not application status codes.

5xx Server Error

500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates (RFC 2295 )
507 Insufficient Storage (WebDAV) (RFC 4918 )
509 Bandwidth Limit Exceeded (Apache bw/limited extension)
510 Not Extended (RFC 2774 )

2xx Success

200 OK
201 Created
202 Accepted
203 Non-Authoritative Information (since HTTP/1.1)
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status (WebDAV)
aleemb