Sure, the original thesis (by Roy Fielding) mentions some disadvantages of the constraints that are the basis of REST:

Stateless:

    The disadvantage is that it may decrease network performance by increasing
    the repetitive data (per-interaction overhead) sent in a series of requests,
    since that data cannot be left on the server in a shared context. In addition,
    placing the application state on the client-side reduces the server's
    control over consistent application behavior, since the application becomes
    dependent on the correct implementation of semantics across multiple
    client versions.

Cache:

    The trade-off, however, is that a cache can decrease reliability if stale
    data within the cache differs significantly from the data that would
    have been obtained had the request been sent directly to the server.

Uniform Interface:

    The trade-off, though, is that a uniform interface degrades efficiency,
    since information is transferred in a standardized form rather than one which
    is specific to an application's needs. The REST interface is designed
    to be efficient for large-grain hypermedia data transfer, optimizing
    for the common case of the Web, but resulting in an interface that is not
    optimal for other forms of architectural interaction.

Layered System:

    The primary disadvantage of layered systems is that they add overhead
    and latency to the processing of data, reducing user-perceived performance.

I fully recommend reading the thesis instead of relying on the vox populi that often times misrepresents what these concepts really mean and what advantages they bring to the architecture of the system: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch...

Ah - I deserved that. I have a copy of his thesis printed out and sitting on my desk but I haven't read it yet! :-)

Definitely. REST(ful) APIs are good approach for where you have clearly identifialble resources, which is what they are all about. But if your API is more procedurally oriented -- take as a clear example a simple Web search -- than REST is not the most optimal approach.

There are plenty of situations where most of RESTful idea has no meaning.

Zemanta's API is one of them. We're not dealing with resources, we're dealing with analysis of text (natural language processing, information retrieval, etc...), so except of the basic url scheme, there's not much that you can take from the RESTful idea.

Dealing with resources is just a point of view. Reading the documentation, it seems very easy to model it in a resource-oriented way; in fact, what they call "objects" (articles, keywords, etc) are essentially resources, which are created from the original resource (the text you submit).

You could just POST the text, get back a bunch of links to the resources and then GET the ones you're interested in.

Assuming that certain "objects" are more expensive than others to generate, a resource-based view with lazily-generated representations could be more efficient than wasting resources without knowing if the client needs them or not.

They are not created in any persistent way. They are entirely ephemeral to that specific request.

What's expensive is the analysis of the original text, not creation of the objects. If you want to do what you are saying you would need to create and store objects server side in order not to have to re-do the analysis the second time around. There's no point in that.

Sure, I was mostly replying to the "we're not dealing with resources" statement. I didn't mean to imply that you should use a RESTful approach.

When you're offering to large old-ish enterprises like banks and such you will likely want to go with SOAP.

When you have a lot of high-speed data, you will want to go with sockets and a live stream of small bits of data. Like Twitter's firehose for instance, or getting Wall Street data for your bot trader.

First you use SOAP and it's nice, but after a while it's not good enough and you implement WSDL. Corporate overlords see it and suddenly everything has to be WS-YouNameIt (especially in banks and big telco). You end up in the deepest valleys of XML hell, colloquially known as WS-DeathStar.

Do to my consulting work, I've been several times through such walk.

You can have both, and you can do it in a consistent way. Not that you can make everybody happy, but it's close enough.

For example we implemented our API with both XML-RPC and REST + JSON interfaces (http://www.memset.com/apidocs/intro.html). All the methods are available and work the same way in both interfaces. There's some extra work to deal with some of the types (ie. dates in JSON), but it's not too difficult.

So we have one implementation/docs, but two interfaces to access to it.

Salesforce seems to do a good job of offering a "enterprisey" SOAP API and nice and simple RESTful API.

Edit: One of the interesting things about their RESTful API is that different versions of the API are explicitly in there as resources.

Actually, the difference between XMP-RPC and REST is not just in the format of the response, the difference is the whole approach. The way you have described (didn't go into the docs) you don't have REST at all, just XML-RPC that returns JSON. Sorry if I misunderstood.

There are two different interfaces for the same implementation. Let me stress the different part. The RESTful API uses JSON to encode the responses, but that's all.

Sorry if I didn't explain it very well, the docs are clearer though.

The point is that your RESTful API is not RESTful at all. It's just RPC using JSON. REST is an architectural style that models the interaction around data and hypertext instead of actions.

A good rule of thumb is: if the documentation mentions "methods" as anything other than the uniform ones (if you're using HTTP, that would be GET, POST, etc), then it's RPC, not REST.

Note: I'm not saying your API is bad; RPC is a completely valid model. I'm just saying it's not RESTful.

That's true, we don't use HTTP methods (PUT, GET, POST, DELETE, etc) as part of the API. In fact we treat POST/GET the same for ease of use.

EDIT: to be fair, in the docs we never say it's a RESTFul API, it was MY mistake in my first comment.

You might want to offer pub/sub API, and it just can't be done with REST because of it's statelessness.

You're not supposed to have session state - but the resources you are accessing are (of course) stateful. Why not set up your subscriptions explicitly as resources that can be manipulated through the API?