andrew carter

Part of my job lately has been to look at how our service is architected. We have a mix of Java and Rails applications but these are not exactly what people call web services. We know we want to turn more of our functions into services but in what way?

I had heard of REST but honestly didn’t know that much about it. I had a tiny bit of exposure to SOAP and had heard more than a few war stories about how heavy it is (whatever that means). Enter REST (Representational State Transfer). I knew Amazon Web Services used REST and was generally popular with developers. I expected I would be learning a new protocol. I was wrong.

REST is more of a design pattern. It uses existing capabilities, particular HTTP verbs. It maps CRUD (Create/Read/Update/Delete) to HTTP POST/GET/PUT/DELETE. It also strongly maps to using resources instead of RPC style calls.

Example:

RPC style


http://webservice.example.com/store/getCustomer?id=1


REST style


http://webservice.example.com/store/customer/1


It may not seem like much but once your entire API looks like the second case, it is a big deal. The hard part was accepting this thought process. You must think more carefully how you expose new functionality. Violating the REST principles in just one place sort of makes all that work worthless.

So after spending about 3 weeks getting the REST religion, we have a couple new internal services to show for it. I feel like an evangelist as I try to get our other developers on board. REST brings out some of that same giddy developer irrationality. But I think that this approach makes sense and we’re seeing it in action.

Being the pessimist that I am, I now want to know why REST is wrong. Nothing is free and I’m sure there is a bunch of gotchas waiting with this as well.