A long time ago in a galaxy far, far away ... OK, not quite. But some time ago our industry spent a lot of time and effort on discussion the pros and cons of REST, SOA, SOAP (!) etc. I even had a few things to say on the subject myself. To misquote Jeff Wayne, "minds immeasurably superior to my own" on the topic of REST and HTTP at the time had a lot more to say and do in this area. It's something which is easily Googled these days. Covered in books too. Probably even several video master classes on the topic of REST and HTTP, let alone their relevance to SOA. And yet it seems that some people either have a very short memory, didn't understand what was said, or perhaps didn't do their homework?
I'm specifically talking about how REST plays into the recent microservices wave. Yes, I think there are some problem areas with microservices and yes, one of them is the dogmatic assertion by some that REST (they tend to really mean HTTP) is mandatory. I don't believe that. I do believe that different message exchange patterns may be suitable for a range of microservices and to limit ourselves to just one (HTTP) does not make sense.
Oh and yes, it still frustrates me to this day when people talk about REST and they're really talking about HTTP - my only consolation here is that if I find it frustrating it must really annoy the h*ll out of the RESTafarians! Not all REST is HTTP and likewise not everything which uses HTTP is necessarily REST. Simple, huh? Well you'd think ...
Anyway, putting that aside, what's got me more frustrated recently is that some people are suggesting that REST (really HTTP) can't do async for microservices and therefore can prevent you breaking apart your monolith. I'm not even going to attempt to explain in detail here how that is wrong except to suggest that a) those people should go and read some InfoQ articles from the early 2000's (yes, even theserverside had things to say on the topic), b) do a Google search, c) read something from my friend/colleague Jim Webber, Savas and others on the topic of REST (and maybe Restbucks - hint, hint), d) in case they're confused between REST and HTTP, maybe go and read the HTTP response codes and look at those in the early 200's range (again, another hint). As I said above, I'm not suggesting there aren't some issues with REST/HTTP for microservices. And as I've also said over the last decade or so, maybe there are some issues with building some types of distributed systems with REST/HTTP. But this isn't one of them!
And this then brings me to a related topic. And if he hadn't been saying it around REST, I'm pretty sure Inigo Montoya would've been saying "You keep using that word. I do not think it means what you think it means" about "asynchronous". Yes, some of the authors try to make the distinction between a blocking call within a single address space and a one way interaction with a service across the network, but that really doesn't instil me with confidence that they know what they're talking about. If they threw in a bit of Fischer, Lynch and Patterson, rather than the oft overused reference to CAP, then maybe I'd be slightly less concerned. But that'd require some homework again, which they don't appear to want to do! Oh well, good luck to those who follow them!
Note, I have deliberately not included many links to things in the post in the hopes it will encourage the reader to follow up.
I'm specifically talking about how REST plays into the recent microservices wave. Yes, I think there are some problem areas with microservices and yes, one of them is the dogmatic assertion by some that REST (they tend to really mean HTTP) is mandatory. I don't believe that. I do believe that different message exchange patterns may be suitable for a range of microservices and to limit ourselves to just one (HTTP) does not make sense.
Oh and yes, it still frustrates me to this day when people talk about REST and they're really talking about HTTP - my only consolation here is that if I find it frustrating it must really annoy the h*ll out of the RESTafarians! Not all REST is HTTP and likewise not everything which uses HTTP is necessarily REST. Simple, huh? Well you'd think ...
Anyway, putting that aside, what's got me more frustrated recently is that some people are suggesting that REST (really HTTP) can't do async for microservices and therefore can prevent you breaking apart your monolith. I'm not even going to attempt to explain in detail here how that is wrong except to suggest that a) those people should go and read some InfoQ articles from the early 2000's (yes, even theserverside had things to say on the topic), b) do a Google search, c) read something from my friend/colleague Jim Webber, Savas and others on the topic of REST (and maybe Restbucks - hint, hint), d) in case they're confused between REST and HTTP, maybe go and read the HTTP response codes and look at those in the early 200's range (again, another hint). As I said above, I'm not suggesting there aren't some issues with REST/HTTP for microservices. And as I've also said over the last decade or so, maybe there are some issues with building some types of distributed systems with REST/HTTP. But this isn't one of them!
Note, I have deliberately not included many links to things in the post in the hopes it will encourage the reader to follow up.
Hi Mark, I suspect that a presentation that I've been giving, "Rethinking REST in a microservices world", has at least partially, if not completely, been the trigger for you writing this blog post.
ReplyDeleteA talk title, and much less, a tweet about a talk, could never adequately describe the full content of a talk, so I can understand how easily someone might come to the conclusions about it that you've come to. If you're interested in watching the presentation, here's a recording of it:
https://vimeo.com/163760711
In case you don't have time or aren't interested in watching it, here's some of the pertinent points that it makes which are relevant to your criticisms:
* In the presentation, I make it clear that I'm talking about the HTTP implementation of REST, or as I put it, "what 99% of developers hear when anyone uses the word REST".
* I also make it clear that any synchronous messaging protocol can be used for asynchronous messaging, and point out that HTTP has a way of semantically indicating this, the 204 response code (there are two dot points in my slides that specifically refer to this).
* And finally, I say "REST is not really the problem", and explain that there are plenty of places in microservice systems where it's appropriate to use REST, HTTP or otherwise.
The point of the presentation is that the blind application of synchronous HTTP REST calls between services in places where people would, in a monolith, use a method call between components, is wrong. In order to realise the advantages of microservices, to achieve the isolation between services necessary to build scalable and resilient systems, you have to redesign your architecture and replace what used to be synchronous messaging paths with asynchronous message flows.
Hi James.
ReplyDeleteIt wasn't your presentation which triggered my article but I'll definitely take a look, so thanks for leaving a comment. Hopefully you'll have seen the update to this entry which I posted the other day too and that covers some of what you've mentioned.
http://markclittle.blogspot.co.uk/2016/04/an-update-to-my-microservices-rant.html
> Note, I have deliberately not included many links to things in the post in the hopes it will encourage the reader to follow up.
ReplyDeleteWell Mark, that is not very RESTful of you... ;-)
> Note, I have deliberately not included many links to things in the post in the hopes it will encourage the reader to follow up.
ReplyDeleteWell Mark, that is not very RESTful of you... ;-)
I'm so glad you mentioned "Fischer, Lynch and Patterson." I reference FLP all the time and get quizzical looks.
ReplyDeleteI'm so glad to see Fischer, Lynch and Patterson mentioned. I reference FLP all the time and get quizzical looks.
ReplyDelete