BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Presentations REST Considered Harmful

REST Considered Harmful

Bookmarks
31:07

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.

Recorded at:

Jul 12, 2016

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • 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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT