REST API Alternatives(blog.programmableweb.com) |
REST API Alternatives(blog.programmableweb.com) |
1) Asynchronous APIs
There's nothing about REST that says that operations must be performed synchronously. If a client updates a resource via a PATCH method and other services are notified of the update via a web hook or a message bus (possibly including the PATCH or the full resource), the system is still following a RESTful design.
2) Orchestration / Experience APIs
A RESTful API does not need to require a separate GET for every individual resource. There's nothing wrong with implementing bulk queries that return variable projections of the server state tuned to the need of particular use cases.
Bulk modifications are trickier, especially when atomicity comes into play. But if atomicity is not a concern, then this is more of a transport problem, not a semantic one.
4) Binary protocols
Plenty of RESTful APIs (e.g., Twitter[1]) provide data in a number of payload formats. Choice of wire format is unrelated to whether or not the semantics of the API are RESTful.
[1] https://dev.twitter.com/docs/things-every-developer-should-k...
This is very much different than the normal REST philosophy of returning only homogeneous results. Much more RPC-ish.
Is that a thing? If 'GET /dashboard.json' obeyed the caching semantics of the resources it pulled together to present, and didn't have any surprising side effects, I'd still call that RESTful, even if it returned a rich graph of interesting data.
Beyond that though, customers often request changes, additions, optimizations, etc., and as they're paying us money, we try to be as accommodating as possible. In many cases, these endpoints are customer-specific, and violate the living daylights out of the RESTful design paradigm -- often exposing 'flattened' views for convenience.
To use the Github API for reference, to get the status of an issue, you have to query the issues for the repository, then the comments and events for the issue, and then the commit messages that are associated with the events.
An example of a non-RESTful paradigm is to simply JOIN the issue's comments and events and associate the relevant commit messages to the events so that they can all be captured in one call.
It isn't truly RESTful, but it's awfully damn convenient pertaining to customer overhead, and we still call it REST, and they don't bother correcting us.
This doesn't violate REST. The WWW is the canonical RESTful system, i.e. A client enters the API (a website) via a common entry point (example.com), navigates using links, and manipulates state using a shared understanding of a common media type (HTML and HTML forms). Think about it, when you go to a web page do you expect it to be about strictly one thing, e.g. when viewing a blog post, do you expect it to click a link to navigate to each comment? No, that would be insane. Does that make it non-RESTful? No. It is perfectly reasonable for a resource to be composed of other addressable resources.
What this means in practice is that the client specifies (usually with a query parameter) what related resources they are interested in, and the server can pre-fetch those resources and include them in the response.
Obviously there's some upfront development costs and your API needs to have a well-linked taxonomy of resources, but it allows the client to create these 'flattened views' on the fly with no further work on your part.
Edit: Just wanted to clarify that IMO this is a RESTful design because you are still using links to navigate your API resources, you're just writing a "smarter" server that can reduce the number of requests.
[0] https://github.com/BetSmartMedia/lazorse-nesting
edit: fixed link
BEEP: http://www.aspl.es/vortex/
BSON: http://bsonspec.org/ (Binary Json)
[0] http://en.wikipedia.org/wiki/Bencode [1] http://tnetstrings.org/
and OSC: http://opensoundcontrol.org
and ASN.1 http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One
God how I hated grad school.
Better title: "Is using REST for everything a bad idea perhaps?" Turns out that yes, yes it is.
For the vast majority of these uses, "REST" is a worthless and meaningless buzzword, so that's not a better title as the rise and fall of "REST" has nothing to do with it.
The entire article can be summarized as "At first we wanted to design pure things, but then we realized we need optimizations as well. Is this the dead of purity in design?" It just makes no sense at all.
Then again, most "REST" as practiced for intra-business data is not really "REST" as far as purists would be concerned; while we at least do things like use HTTP error codes instead of an HTML page with "error" on it under a 200, I'd be laughed out of the conference room if I suggested our clients use a PUT instead of a POST. But who cares, as long as it's not SOAP.
So I reckon the REST is dominating the field, SOAP is on the way out and JavaScript is the little upstart that could?
I don't think the person writing this article has any grasp on what REST actually is. If they knew they wouldn't be comparing it to the "Asynchronous APIs". I use asynchronous API's everyday. And some of them are RESTful and I prefer them over those that are not.
I keep trying to read the article and I have huge problems. I recognize the words, but I have no idea what the author is trying to say.
1. REST is not inherently uni-directional. This is especially going to be the case in the internet of things, where you're just as likely to have servers on both ends. 2. You can do server->client push with Server-Sent Events.
To start with:
1. Label your axis, that graph doesn't say anything.
2. Maybe we should be looking at percentage change in the graph rather than whatever is being graphed here.
Instead, to me, it seems like he's trying to justify that statement with a poor microsoft office graph.
deep ops on multiple objects complicate things even further.
i feel like once you get outside the realm of basic document storage (which is what HTTP was designed for), REST via HTTP headers completely breaks down into custom hackery for which there are no standards.
I've used this approach for exactly the situation you're describing: batch operations that return multiple entities.
But with async, you send a message and that is it. This can be implemented on top of HTTP RPC such as with Websockets, but the HTTP layer is unnecessary. Messaging using the AMQP protocol is a nice alternative. You can open a socket and hold it open for sending and receiving messages. When you send a message, it can be received by an MQ broker like RabbitMQ for guaranteed delivery to whatever internal service(s) need to process it. And when some kind of result needs to be sent back to the message originator, the socket is open and ready to receive it. For those things where the app needs RPC, it is simple to send a message and wait for a reply message. But when all you need is a notification going out, or coming in, that works too.
While MQTT and ZeroMQ and others could be used, it would be nicer if the Internet standardized on AMQP at a known port (just like HTTP) and even included the use of an MQ broker with all the optional services (topic queues, persistence, guaranteed delivery) that can be provided.
Not that this scales as well as message service "topics" (with multiple subscribers/listeners), but it's a start, and doesn't sound much worse than the load for point-to-point queues.
The concept of poking about with HTTP to try and treat it vaguely like a TCP style transport protocol is rather silly.
If you think about how "wordy" HTTP is, along with the standard RESTful verbs, you'll start to think "hmmm, perhaps this isn't the best way."
Websockets and if you must a bit of JSON (binary if done properly is lower latency and much more efficient) should be the way forward.
yes its a bit harder, but you know, its smaller, better, more efficient.
High volume: custom-binary wins, just like you said. Low volume: REST/text wins.
There's something to be said for being able to try out your API in a web browser in 2 minutes. Compression also goes a way in reducing the volume of text, though not the latency of follow up queries that are too finely granular.
Small, sharp, tools swapping text is very unixy. Even if sometimes the response is a binary document :-)
Let's start with asynchronous API. You can easily POST a request, get a new URL back, the just poll it until you get a result (returning 202 in the meantime). The simplest article explaining it can be found here:
http://www.infoq.com/articles/webber-rest-workflow
It's not even that hard - almost every website that generates non-trivial reports does it somewhere. REST hides all the implementation details behind simple resources (URLs in the HTTP world).
Orchestation: Go look up SPARQL. Yes, the language itself isn't pretty, but it's proof that you can orchestrate some pretty complex reports if you like. As pcl notes, you can do it with simpler URLs too. It's all down to the web service.
For SDKs... they tend to be reserved for the nastier APIs (usually involving XML).
Binary protocols? Seriously? There are entire theses dedicated to the fact that HTTP was designed to deal with this stuff. Go read the documentation on HTTP Accept headers.
I'm not surprised there are badly designed HTTP interfaces out there; but criticising the architectural style itself based on your own lack of knowledge helps nobody.
A typical RESTful API:
PUT new data to resource x/y/z
An asynchronous non RESTful API:
POST job information for resource x/y/z
GET status of job for resource x/y/z until status is complete.
GET results of job for resource x/y/zThat is all RESTful. Whether or not its useful is a different question.
Your second example is only asynchronous in so far as you are oblivious to the completion of of the request, but that hardly makes it non-Restful. To me both of your examples are REST by definition.
A good module that uses this philosophy is:
https://github.com/substack/shoe
As with everything - pick the right tool for the job. It helps to have more rather than less tools.
A more productive discussion might have started with Ext.Direct or Dojo RPC, but even those are just complementary channels, not alternatives.
So in short - no, REST works, use it in the right places, and remember kids - not every Web service or endpoint has to expose a REST based interface.
I've experienced a lot of pain trying to get working clients generated and configured from some magic WSDL (SOAP interface definition file), though. For a supposedly self describing standard, each time I have had to write a client, it was very much an "interesting" adventure.
My gut tells me there are many "Web Services" consultants who do not like REST because it simplifies things to the point where they are out of a job :-)
Reading comprehension, you definitely don't have it. I didn't say REST wasn't well-defined or was worthless, I said most of the uses of the acronym are as a worthless and meaningless buzzword, having very little to do with REST itself. That is a very different issue.
And since most of the uses of the "REST" acronym have little to do with actually RESTful system, the rise and fall of the buzzword has no relation with the rise and fall of RESTful system (which, objectively, have had very little rise in the first place)
Several times, in the past couple years, I've actually written internal translation services in node.js against public soap endpoints that I can more easily consume (usually in C#/.Net)
Also, I've seen a lot of SOAP written in Java as well... Though the couple of PHP "SOAP" services I've had to consume have been the worst by far.
Also, I have never read anything implying POST requests are incompatible with REST.
This kind of heterogeneous data tends to be very much discouraged under REST, but often very handy in producing real world reports.
/dashboard?type=orders&type=customers&type=support
With either some documentation explaining the differences, or even the return value itself describing what's in e.g.
{"orders": {"date": "today", "data": [...]}, ... }
What you return depends entirely on the context of your web service. If people are telling you to always return a homogenous set of results then they're wrong. You know your application better than some random guy on the internet.
This is nothing to do with REST. Read the Wikipedia article for a crash course.
Perhaps I should have said discouraged in the common patterns for implementing REST and REST-like APIs.
If one correctly leverages hypermedia, you may and most likely will have heterogenous responses and relations. Side-loading relevant relations is highly encouraged and is a core component of efficient API design.
To your credit, I believe most of the information out there about REST and REST-like APIs discount how much work actually goes into building a proper REST API with hypermedia -- so we will always have half-baked design patterns that solve problems when doing REST incorrectly.
I think the easy and normal and common path is to have canonical uri for ressources, and to serve agregated content for convenience or speed on other entry points, while adding to agregated content pointers to canonical uris.
No?