A lot has been written about the difference between REST APIs and SOAP Web Services. The technical differences are well known at this stage. SOAP is heavyweight, while REST is light and mobile-friendly. However, there is another key difference which is often overlooked:

• It is easy to create SOAP Web Services, but difficult to consume them.
• It is difficult to create a good REST APIs, but easy to consume them.

Taking SOAP first: development platforms such as .NET made it almost too easy to create a SOAP Web Service. I remember seeing MSDN demos showing how, in a few clicks, you can take a .NET object and expose it as a Web Service, complete with WSDL. But, in those quick clicks, what had you created? You had exposed the methods of your objects as SOAP operations. But why? Is this really what you wanted to do? And while it was easy to say "Clients can just consume the WSDL to call my new Web Service", this was easier said than done. And when clients did this, it often made little sense to directly run the methods of the class.

Fast forward to the world of REST. One of the great virtues of REST is that it is so much easier to consume a REST API, compared to consuming a SOAP Web Service. In addition, it does not require parsing XML, if you prefer to directly read in JSON. However, creating a good REST API takes thought and some decisions. You should think about how you'll appropriately use the HTTP verbs, how to express versioning, and what kind of error messages you'll return. Fortunately, an API Server helps a lot here, by providing a platform for delivering APIs, to take care of aspects like security, usage quota-management, and analytics. But it still is important to take time to design your API up front.