@paulrbrown thanks. now let’s see how many people read into it things I didn’t say. about 5 hours ago
Well, it didn’t take long, in fact, two hours earlier:
Hey everybody, you’re allowed to not use REST now, as long as it’s in private. This indulgence comes too late for some services, but we’ll all sleep better knowing RESTitecture police have called off their bedroom raids
I looked around and couldn’t find the badge, must have been lost in transport, so I went and created one.
But jokes aside, here are a few points to consider.
#1 Don’t use RPC to build distributed systems. (SOAP folks would tell you that as well) But you have to wonder what distributed means. Taking a piece of code and moving it to a different server in the same rack space, is not distributed computing. It’s just SMP with multiple power supplies.
But then again, I never though that running a web server with a database server is a distributed system. Other people may do, so it’s a matter of semantics. I’m looking at a higher bar: separate applications, separate developers, separate owners, separate networks, separate concerns. And what’s not distributed today, can be, tomorrow.
#2 Serendipity is also cool, but it’s one of those things that, if your architecture lacks you won’t know you’re missing it. Lost opportunities are hard to measure, and by the time you notice, might be too late. And don’t overlook affordances.
#3 If you think SOAP is just RPC, you’re either wrong or trying to prove something. It only looks that way because a lot of people are either lazy or hammering it. News flash. You can do RPC and slap a REST sticker on it. A lot of people do that as well, doesn’t mean it must happen to you.
#4 Sometimes you use RPC. Sometimes you use REST. Sometimes you use queuing. Sometimes you use streaming. Sometimes you pub/sub. And don’t forget about this.
With a few exceptions: there will always be cases when you need to tunnel one architecture style over another.
If that describes you, I’m guessing you’re spending just as much time as I am, honing your skills and learning what to use, when and how. Apparently, everyone else is just as happy using their One True messaging approach.
#5 REST is like democracy. Yes, I do think it’s that bad, and someday I’ll go over the list of problems, annoyances and false assumptions. But you have to remember that, as much as I like to complain about spotty coverage and lousy battery life on my cell phone, I have no intent of giving it up for a land line.
#6 Most people will do it wrong. Again, to paraphrase Churchill, the best argument against REST is a five-minute read of rest-discuss. You get the same problem with SOAP (along with all the other “fun” stuff).
And wait until people start building architectures around Google’s Protocol Buffers, because if Google uses RPC, surely it must be good enough to be used everywhere for everything. You get massive scalability for free, right?
Oh, wait, search results and crawlers are the stereotypical example of REST in action, map/reduce is loosely coupled and asynchronous, the public APIs are Atom-like, and what was that about streaming and pub/sub? Never mind.
#7 Once you use SOAP enough, it’s hard to remember what was wrong with RPC.
Although, I would have to say that I’m eternally grateful for SOAP. It spared us from so many architecture disasters that came before it, and a few that didn’t come because of it. Too bad it couldn’t save itself from itself.
But yes, from my experience so far, REST is teh awesome for the stuff you see, and RPC is convenient for the stuff you don’t. Just like Natah observed. But I also learned that not paying attention and being selective with the RPC you use will come to bite you when you least have time to deal with it. Which is why I think Rullet is such a fitting term.
flash my rack
Labnotes » SOA and the statistical non-FAIL