Cloud-based API data models have not only enhanced the cloud experience, but also provided a way for developers and administrators to integrate workloads into the cloud using those APIs. For most enterprises, APIs let share information across various on-premises and cloud-based applications. They also play an important role to integrate platform workloads more seamlessly. As cloud adoption continues to grow, there is more demand for integration points between applications inside and outside of the cloud environment. Rise of multicloud strategy along with need for enhancement in cross cloud capabilities have increased the dependency on cloud API environment. But which approach is better and what support do you get in your cloud environment?
SOAP in a nutshell
SOAP (short for Simple Object Access Protocol), the older approach, had industrywide support ranging from product companies such as IBM and Microsoft to service implementers. It also came with a comprehensive yet complex set of standards. Microsoft team who designed SOAP made it to be extremely flexible—to be able to communicate over private networks, across the internet and emails. It was supported by several standards as well. Initial version of SOAP was part of a specification that contained Universal Description, Discovery, and Integration (UDDI) and Web Services Description Language (WSDL) as well.
SOAP essentially provides the envelope for sending the web services messages. The architecture itself is designed to help the performance of various operations between software programs. Communication between programs usually happens via XML based requests and HTTP based responses. HTTP is mostly used protocol of communication, but other protocols may be used as well.
A SOAP message contains some mandatory parts such as ENVELOPE, HEADER, BODY, and FAULT. The ENVELOPE object defines the start and end of XML message request, HEADER contains any header elements to be processed by the server, and the BODY contains the remaining XML object that constitutes the request. FAULT object is used any error handling.
REST
REST (Representational State Transfer) is usually referred as an architectural style rather than a protocol, which is used to build web services. REST architecture allows the communication between two software programs, wherein one program can request and manipulate resources from the other one. REST request for accessing resources on target program uses HTTP verbs: GET, POST, PUT, and DELETE. These requests can use data format including XML, HTML and JSON. JSON is most preferred as it is most compatible and easy to use. most REST APIs are based on URIs (Uniform Resource Identifier) and are specific to HTTP protocol.
REST is developer-friendly because its simpler style makes it easier to implement and use than SOAP. REST is less verbose, and less volume of data is sent when communicating between two endpoints.
Why SOAP or REST?
While SOAP is like using an envelope that contains lots of processing information inside it, REST can be considered a postcard that has an URI as destination address, is lightweight, and can be cached. REST is data-driven and is primary used to access a resource (URI) for certain data; SOAP is a protocol that is function-driven. REST provides flexibility in choosing data format (plain text, HTML, XML, or JSON) while SOAP only uses XML.
SOAP is suited well for applications where you need higher level of security. SOAP comes with enterprise-level security features supported by WS-Security, along with SSL support. If you are looking to develop a mobile banking solution, SOAP APIs would probably be the first consideration for security requirements. SOAP also provides a retry logic for guaranteed success and reliable communication. REST uses HTTP and can address communication failures only by retrying however the retry logic doesn’t come in-built with REST. SOAP does provide built in retry logic.
What changes in a cloud-native environment?
From a developer’s perspective, nothing really changes in choosing between REST or SOAP, but designing your service in a cloud-native environment brings platform perspective into considerations. Service availability and response time plays a critical role in designing enterprise services and cloud native applications. From a security standpoint, WS-Security (Web Service Security) protocol, which provides end-to-end message level security using SOAP messages, is widely applied in cloud computing to protect the security of most cloud computing related web services. But WS-Security uses SAOP header elements to carry security-related information. A SOAP message is of XML-type format and is normally much bigger in size than the actual message in a binary format. This increases the time and processing to communicate and process the data. This can be argument of debate for choosing REST versus SOAP, but there is shift from SOAP to REST irrespective of the platform your application is going to run on.
Late in 2016, Microsoft Azure added SOAP passthrough support to Azure API Management that helps developers to create a proxy for their SOAP APIs in the same way they create proxy for REST/HTTP APIs. Using SOAP passthrough support, you can import WSDL documents and create a new API proxy; the process looks at all SOAP actions in the document and effectively creates those into API endpoints. In a future version, we might see a feature requested to create REST front end using a SOAP back end.
Inside AWS world, most of the AWS APIs are accessible only via REST and have limited support for SOAP. EC2 resources are available via REST or Query API, while SOAP API for EC2 has been deprecated since late 2015. Services such as Amazon S3 and RDS also supports REST while SOAP is only supported via HTTPS; SOAP for HTTP is deprecated. Amazon SQS doesn’t support SOAP anymore. While REST seems to lead AWS APIs, the Amazon API Gateway integrates with the AWS ecosystem and provide support creating, managing and deploying a RESTful API to expose back-end HTTP/HTTPS endpoints, AWS Lambda functions, and/or other AWS services. API Gateway also helps Invoking exposed API methods through the front-end HTTP endpoints.
More and more support leans towards RESTful APIs. Its simplicity with verb-like operations makes it developer-friendly. It’s compatible with most formats and is easy to use. There is no sunset for SOAP either, but REST is definitely going to be popular among the developer community.