InfoQ Homepage Presentations REST Considered Harmful
REST Considered Harmful
Summary
Ross Garrett explores how design decisions may be leading to poor UX, discussing the principles of reactive applications and how streaming APIs can deliver significant benefits over RESTful APIs.
Bio
Ross Garrett runs Product Marketing at Push Technology, where he is responsible for market strategy and product positioning. He has over 10 years product leadership experience in the API space.
About the conference
APIdays is the largest Australian conference dedicated to the business and technology of Web APIs. It brings together business leaders, entrepreneurs and technologists to discuss, collaborate and learn about building the platforms that support new business models.
Community comments
REST and reactive
by Rickard Öberg,
REST and reactive
by Rickard Öberg,
Your message is awaiting moderation. Thank you for participating in the discussion.
This talk is not only title-click-baity, it's "not even wrong". The talk has nothing to do with REST. It doesn't even have anything to do with Web APIs ("web" suggests links, which require hypermedia, and so you have REST, or Level 3 systems). The true topic is what happens with badly designed "JSON over HTTP" APIs.
On the reactive topic, I have built a reactive streaming system using REST. Works like this: use Atom as hypermedia format. Client polls the atom feed for new events. It's a long poll, so if there are no new events, then return response only when there are, or after a timeout. Since reactive systems require that client sets pace this works great: client does request, gets batch of events, process them, and at the end makes a new request. Both client and server can be made to use asynchronous calls so threads are not used up. In some cases (server2server) you can avoid the polling completely by using PubSubHubbub.
With web sockets it can be easy to screw this up. If the server sends events when they are available that is by definition not reactive. You need to design it so that server only sends events when client asks for it.
For the "server sends too much" argument, this is a feature of "JSON over HTTP" APIs. In RESTful systems the client can only do two things: follow links and submit forms. In my system the client can submit a form to get data where one field is what data to include in the response (like a "select"). So if the server has 10 fields but the client just wants 2, then the client can decide that by filling in the form correctly. That's how a RESTful system works.