by
Join the DZone community and get the full member experience.
Join For FreeA 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.
SOAP
REST
Web Protocols
Published at DZone with permission of Mark O'Neill, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments