tags:

views:

88

answers:

5

Our web service only supports JSON. We respond with JSON if we can or respond with an HTTP Error 406: Not acceptable if the client asks application/xml... Is it still considered RESTful?

+8  A: 

Yes. The REST principles builds on the original intentions of the HTTP protocol. There is no requirement to use XML. Actually, XML didn't even exist when HTTP was created...

Guffa
A: 

Personally, I would still consider it RESTful. But that may just be an opinion.

It really depends on your audience. If they do not demand an XML interface, I see no reason to provide one. But if you are attempting to provide the largest range of support and clients, you may want to consider adding XML support.

I have a RESTful API that only provides JSON and I have no intention of providing XML.

Tauren
+1  A: 

You don't have to offer an xml format, but be prepared to deal with annoyed developers. If you want your API to be widely used, you should try and keep developer ecosystem happy.

Adam
Which, of course, can depend greatly on the *makeup* of your developer ecosystem. Personally, I wouldn't give two bits for XML, but would be greatly irritated if it didn't support JSON. ;-)
Ben Blank
I was looking at what twitter (the posterchild for a widely used API) does. They have both - but they recommend the json api.
Adam
A: 

REST is not inherently XML-oriented.

Any media type can be a resource.

You just need to declare the media type in the HTML Content-Type header.

Jay
A: 

Well the first question is, does it matter if it's not RESTful? As long as the API is well documented and works for the people who need to use it, I'm not sure this is a concern.

Secondly, REST has less to do with the content of the requests and responses and more to do with how the requests are made. REST in HTTP usually means each API call uses the correct HTTP method to respond to something, and that the URL's are representative of something as well.

For example:

  • GET /foo <-- GET requests mean downloading, or reading something
  • POST /foo <-- POST means sending data, or changing
  • PUT /foo/bar <-- PUT is often used for uploading new resources. It is often expected that when you PUT an object at a URL and it succeeds, that you can re-get the object again at the same URL.
  • DELETE /foo/bar <-- should be obvious

For example, if your API had a single URL endpoint, and the method was chosen by something inside the POST data, then it's probably not RESTful. On the other hand, if each URL represented a resource, and the API was used by traversing URL's, and that anything that changed something used POST/PUT and anything that queried something used GET, it's what most would consider to be RESTful.

Crast
REST has a lot to do with the content of the requests (but the content doesn't have to be XML indeed): http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
Bruno