Post-REST - some thoughts by Tim Bray


#1

In this post, Tim bray looks at a world post REST. Coming from a job where we spent significant time on trying to shoehorn things into RESTful semantics, I find it surprising that I agree with much of his thinking.

“But I bet that for the fore­see­able fu­ture, a high pro­por­tion of all re­quests to ser­vices are go­ing to have (ap­prox­i­mate­ly) HTTP se­man­tic­s, and that for most con­trol planes and quite a few da­ta planes, REST still pro­vides a good clean way to de­com­pose com­pli­cat­ed prob­lem­s, and its ex­treme sim­plic­i­ty and re­silience will mean that if you want to de­sign net­worked app­s, you’re still go­ing to have to learn that way of think­ing about things.”

You can do worse than to familiarise yourself with REST and practice trying to structure problems to use approximately RESTful interfaces.

Article: tbray.org/ongoing


#2

Thanks for sharing.

I see his point, and I don’t see anything new here unless I am missing something. We have been using queuing libraries like Resque/Celery for long running tasks for a long time now. Back in the day, J2EE was built on this model. I wonder if he is making 2 points here. 1 that queues are a way to process long running tasks asynchronously. 2 We should rethink the way we make connections over the internet to either SUPER fast short connections (HTTP/3) or long running connections (web sockets?). This may just be the next incremental thought exercise.


#3

I think there is a growing feeling that REST is tired and that all things gRPC, GraphQL and whatever else come along next are the future. I read this as a reminder that we shouldn’t count REST out just yet.

I have had real pain with RESTish implementations in the past so part of me wants to believe it has had its day. For me, the article breaks thing apart a little.

  1. some interactions with datalend themselves very well to RESTful thinking. Tim cites the control plane as an example. There are some data plane problems that don’t lend themselves nicely to REST but that doesn’t mean REST is dead.

  2. The mechanics of transporting data around are a distinct problem. Long running requests, queues and streams are all more popular than ever. As we break services apart the requests between services increase. Understanding tools available, along with their limitations is time well invested. Approaches for mobile app to data centre may be very different to those you adopt within the data centre etc.

In short I think this article is a response to a quiet, but growing, view that REST is old world.