What Will Power the Future of the Internet: REST or SOAP?
I was recently asked why we chose REST over SOAP for our re-write of the FoxyCart.com API, and the short answer that immediately came to mind was, “Because I don’t hate myself”. To expand on that answer, let me give you a little bit of the back story.
FoxyCart was built from the beginning with a desire to integrate with existing systems and avoid duplicating data. We’re not a CMS, we don’t do inventory tracking, customer mailing lists, accounting or analytics. We integrate with the tools you already use. As such, it’s critically important that our data be easily accessible in a way that makes sense. As a tool built by developers for developers, we want to keep things simple without creating “yet another thing” for you to learn or another manual to squint at while building your integration.
As we began our API re-write, we kept these ideas in mind. We didn’t go with SOAP primarily because it doesn’t keep things simple. I’ve worked with SOAP in PHP, Java and ColdFusion (yes, thank you, your sympathy is much appreciated). Granted, it is pretty neat to fire up a tool like soapUI and have a bunch of methods and stubs built out automatically or to see Eclipse parse a WSDL and show you that nifty drill-down-forever interface which exposes the depth of possibilities for the API. However, the real frustration I’ve always had is having to re-learn things I should already know. How do I create something, get it back again, make some changes or delete it? At the most basic level, most method calls can be boiled down to representations of data that just need to be manipulated.
Instead of having to dive into the SOAP API developer’s thought process (often leading to a DailyWTF moment), REST eliminates the confusion all together. Where a SOAP API may have methods like getAllSubscriptions() or customerSave() or filterTransactions(), REST allows us to say, “Here’s the representation, you already know what to do with it.” Ideally, if you’ve integrated with one REST API, you understand them all: GET, POST, PUT and DELETE. We’re all familiar with this thing called the World Wide Web, and it has scaled pretty well over the years following these simple patterns.
The story doesn’t end there. One of the other main reasons to be excited about REST is that it’s still, after all these years, actively being developed and discussed. The API Craft Google Group, as an example, is incredibly active, and they’re not just debating what Fielding really meant in his dissertation over a decade ago. They are helping each other build things right now. Companies like Apigee are creating great content on their blog, educating and improving the entire ecosystem.
New solutions are being proposed such as the PATCH HTTP method for partially modifying a resource. We’re still learning what Hypermedia as the Engine of Application State (HATEOAS) really means. There are plenty of questions like how hypermedia should be represented in JSON or how a client should interact with vendor-specific content types and what code-on-demand can do for you. These questions might seem overwhelming, but for us they are exciting! We believe the future of consistent, powerful API development is being defined right now, and we get to be a part of it.
If Facebook, Amazon, PayPal and Twitter have taught us anything, it’s that building a platform is more powerful than just building an application or a website. APIs are the bones of any platform. REST is the muscle that will get the job done.
***Image courtesy of Delyn Simons, Mashery API Network