Want to connect your app to Instagram to repost images using specific hashtags, or to Facebook so it can create posts automatically? Or maybe you want to embed YouTube videos on your website? You can do all of these things and more with application programming interfaces (APIs).
APIs, such as the Instagram API,
Facebook API, and YouTube API, provide a secure, standardized way for different programs to “talk” to each other. That is, an application can extract functionality or data from another piece of software and use it to improve its own functionality or UX.
But how do apps make these requests, process them, and respond to them in a way the other understands? That depends on how the API was built. Let’s go over the two most common methods below.
Now that we have a high-level overview of the differences between SOAP and REST, let’s take a closer look at how they compare in terms of services, security, and examples.
SOAP vs REST Services SOAP vs REST Security SOAP vs REST Examples REST Example SOAP
vs
REST Services
To compare SOAP and REST APIs, we first need to understand what exactly each API type does.
-
- Services
- SOAP
SOAP
is a standard communication protocol system that uses XML technologies to define an extensive messaging framework that allows structured information to be exchanged in a Decentralized, distributed environment. In other words, SOAP allows applications running on different operating systems to communicate using different technologies and programming languages.
A client can use the SOAP APIs to create, retrieve, update, or delete records, such as passwords, accounts, leads, and custom objects, from a server.
REST Services REST
,
on the other hand, is an architectural style, not a protocol. As stated above, it means Representative Transfer of the State. This means that when a client requests a resource using a REST API, the server transfers the current state of the resource into a standardized representation. In other words, REST APIs receive requests from a resource and return all relevant information about the resource in a format that clients can easily interpret.
In addition to requesting resources, clients can use REST APIs to modify and even add new items on a server using HTTP methods.
For a more detailed description, read REST API: How They Work and What You Need to Know.
SOAP vs Security
REST
Now that we have a better understanding of what the SOAP and REST APIs do, let’s compare their security measures and protocols
.
Safety
SOAP Because SOAP
is a messaging protocol, securing the SOAP APIs focuses primarily on preventing unauthorized access to messages (and the user information contained in those messages) received and sent from the SOAP APIs. The primary defense against unauthorized access is Web Standards (WS) security, a set of principles that govern confidentiality and authentication procedures for SOAP messaging. Measures supported by WS Security include passwords, XML encryption, and security tokens, among other mechanisms.
WS Security goes beyond traditional web security mechanisms, such as HTTPS, which only secures messages during transport between the client that made the request and the server or web service that has the requested data. WS Security, on the other hand, secures messages beyond the HTTPS connection and sometimes even beyond the transport layer.
How exactly does he do it?
A SOAP message contains the information needed to protect it
, or it contains information about where to get the information needed to protect it. A SOAP message also contains information relevant to the protocols and procedures for processing the message-level security specified in its header. That means that when a Web service endpoint receives a SOAP message, it checks the security information in the header to make sure it hasn’t been tampered with. That’s why SOAP is said to have “message-level security.”
Because SOAP supports WS specifications, such as WS-Addressing, WS-Policy, WS-Security, WS-Federation,
WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction, and WS-RemotePortlets, SOAP APIs are ideal for internal data transfers and other sensitive tasks, but unnecessary for using a public web service that is freely available to everyone, such as retrieving weather data. We’ll talk more about when to use SOAP vs REST APIs later in the post.
Safety
REST
APIs only support traditional web security mechanisms, such as HTTPS. That means that when an application sends and retrieves a message from a REST API using HTTPS, the message is only protected for the HTTPS connection. That is, the message is protected only during transport between the client and the service. That’s fine for public web services, but it may not be enough for more sensitive data transfers.
Because REST APIs do not have the built-in security capabilities or extensions that SOAP has, their security depends on the design of the APIs themselves. REST APIs can be designed with certain security mechanisms that ensure that only authenticated and authorized users can access them. Common REST API authentication methods are HTTP basic authentication, JSON web tokens, OAuth, and API keys.
REST APIs should also have detailed specifications and reject any requests that don’t have the correct declarations in their HTTP headers, for example, or that don’t follow their specifications. This will help protect the underlying web application from malformed and malicious input, even after the client has gained access.
SOAP
vs
REST Examples
Let’s compare some examples of requests and responses to and from a SOAP API and a REST API. The following examples are based on the QAComplete SOAP API and the REST API, respectively. QAComplete is a comprehensive software test management tool from SmartBear.
SOAP
sample
Full SOAP requests are HTTP POST requests made to the URL of the Web service endpoint. The client and server exchange data in XML format in the body of HTTP requests and responses.
This SOAP API only accepts HTTP POST requests, but it also supports several common operations for all item types, including Add, Delete, Load, LoadByCriteria, and Update. You’ll see these operations instead of the HTTP GET, PUT, PATCH, and DELETE verbs.
The following sample code requests to obtain a defect by its identifier in a project in QAComplete using the SOAP API. The code snippet is written in XML and uses the Bugs_Load operation
: POST /psws/psws.asmx HTTP/1.1Host: myteam.mysite.comContent-Type: application/soap+xml; charset=utf-8Content-Length: 486 {Insert an appropriate value here}<?xml version=”1.0″ encoding=”utf-8″?><soap12:Envelope xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:soap12=”http://www.w3.org/2003/05/soap-envelope”><soap12:Body><Bugs_Load xmlns=”http://www.pragmaticsw.com/”><AuthenticationData><AppCode>agSP</AppCode><DeptId>7154</DeptId ><ProjId>1032</ProjId><UserId>25315</UserId><PassCode>p@ssword</PassCode></AuthenticationData><BugId>5</BugId></Bugs_Load></soap12:Body></soap12:Envelope>
The response will contain an HTTP status code and a Bug object that contains information about the required defect. It will be written in XML. In the following example, there is an HTTP status code 200 to show that the request was successful, as well as information about the defect in XML: HTTP
/ 1.1 200 OKContent-Type: application/soap+xml; charset=utf-8Content-Length: 2244 {Server returns appropriate value here}<?xml version=”1.0″ encoding=”utf-8″?><soap12:Envelope xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:soap12=”http://www.w3.org/2003/05/soap-envelope”><soap12:Body><Bugs_LoadResponse xmlns=”http://www.pragmaticsw.com/”><Bugs_LoadResult><CustomFields><string>0.9.19</ string><string>1.0.24</string></CustomFields><CustomFieldNames><string>Found in build</string><string>Fixed in build</string></CustomFieldNames><BugId>13254</BugId><Title>Toolbar Floating Enhancements</Title><StatusCode>Resolved</StatusCode><PriorityCode>2-Fix Coming soon</PriorityCode><HowFoundCode> Test-Ad hoc</HowFoundCode ><ResolutionCode>Fixed</ResolutionCode><AssigneeUserId>27942</AssigneeUserId><OpenedBy>27568</OpenedBy><ClosedBy>27942</ClosedBy><ResolvedBy>27568</ResolvedBy><Description><! [CDATA[The floating toolbar design needs improvement to make it clearer what the user needs to do.]] ></Description><Resolution>Resolved by Susan McLaren on 24-Jun-2014 at 03::03:03:03:03 55 PM</Resolution><OwnerUserId>27572</OwnerUserId><TestCaseId>0</TestCaseId><FolderId>52359</FolderId><EstHrs>0.000</EstHrs><EstStart>2014-06-10T10:00:00</EstStart><EstFinish>2014-06-13T10:00:00</EstFinish><PctComplete>100</PctComplete><ActHrs >0.000 </ActHrs><ActualStart>2014-06-17T00:00:00</ActualStart><ActFinish>2014-06-31T00:2014-06-31T00:2014:00:2014 00:00</ActFinish><EstHrsRemaining>0.000</EstHrsRemaining><DateOpened>2014-05-26T15:54:21.093</DateOpened><DateResolved>2014-06-24T15:55:25</DateResolved><DateClosed>0001-01-01T00:00:00</DateClosed><DateUpdated>2014-06-31T05:54:22</DateUpdated><ProjId> 17823</ProjId> <DateCreated>2014-05-26T15:54:21.093</DateCreated><UpdateUserId>27534</UpdateUserId><OriginalId>0</OriginalId><ImportId>0</ImportId><AssignedToName>Doe, John</AssignedToName><OpenedByName>McLaren, Susan</OpenedByName><OpenedByEmail>susan@example.com</OpenedByEmail><OpenedByCompany>Edgar Solutions</OpenedByCompany><ResolvedByName> McLaren, Susan</ResolvedByName><UserName>Fry, Alex</UserName><OwnerName>Davis, Eugeny</OwnerName><NbrFiles>0</NbrFiles><NbrNotes>1</NbrNotes><NbrEvents>0</NbrEvents><NbrTasks>2</NbrTasks><FolderName>FamilyAlbum/Release 1.1/Iteration 1</FolderName></Bugs_LoadResult></Bugs_LoadResponse></soap12: Body></soap12:Envelope>
Note that this SOAP message contains an envelope, a header, and a body element, all of which are required
. REST
example REST
requests
are HTTP requests made to the QAComplete REST API endpoint URL, which has the following format: http(s)://{your-server}/rest-api/service/api/{version}/{resource}. This API uses the HTTP GET, POST, PUT, PATCH, and DELETE methods.
The following sample code requests to get a defect by its identifier in a project in QAComplete using the QAComplete REST API. The code snippet is written in JSON and uses the HTTP method, GET
: GET http://yourserver.com/rest-api/service/api/v1/projects/11873/defects/17 HTTP/1.1Host: yourserver.comConnection: keep-aliveAccept: application/jsonAuthorization: Basic am9obkBleGFtcGxlLmNvbTpwQHNzd29yZA==
The server will return an HTTP status code and information about the defect. In the following example, there is an HTTP status code 200 to show that the request was successful, as well as a JSON object with information about the defect: HTTP/
1.1 200 OKContent-Type: application/jsonContent-Length: 1758{“id”: 17,”title”: “Floating toolbar improvements”,”status”: “Resolved”,”__permissions”: {“acl”: 7},”act_finish”: “2015-06-31T00:00:00.0000000″,”act_hrs”: 0,”act_start”: “2015-06-17T00:00:00.000000”, “actual_results”: “The floating toolbar layout is inconsistent.”,”assigned_to_name”: “Smith, John”,”assignee_user_id”: 27942,”closed_by”: 27942,”custom_fields”: [{“Id”: “Custom1″,”Name”: “Components”,”Value”: “UI”},{“Id”: “Custom2″,”Name”: “Fixed in build”,”Value”: “1.0.13”}],”date_closed”: “0001-01-01T00:00:00.0000000″,”date_created”: “2015-05-26T10:54:21.0930000″,”date_ opened”: “2015-05-27T11:42:29.1700000″,” date_resolved”: “2015-06-24T09:55:25.4500000″,”date_updated”: “2015-06-24T09:55:25.4500000″,”description”: “Floating toolbar design needs improvement”,”est_finish”: “0001-01-01T00:00:00.0000000″,”est_hrs”: 0,”est_hrs_remaining”: 0,”est_start”: “0001-01-01T00:00:00.0000000″,”expected_results”: “This should work”,”folder_id”: 52359,”folder_name”: “Interface defects user”,”functional_area_code”: “”,”how_found_code”: “Code Review”,” import_id”: 0,”issue_code”: “Code Defect”,”nbr_events”: 0,”nbr_files”: 1,”nbr_notes”: 1,”nbr_tasks”: 0,”opened_by”: 27942,”opened_by_company”: “EDGB”,”opened_by_email”: “smith.john@edgb.com”,”opened_by_name”: “Smith, John”,”original_id”: 0,”owner_name”: “Smith, John”,”owner_user_id”: 27942,”pct_complete”: 0,”priority_code”: “1-Fix ASAP”,”project_id”: 11873,”resolution”: “The toolbar has been redesigned”,”resolution_code”: “Fixed”,”resolved_by”: 27942,”resolved_by_name”: “Smith, John”,”severity_code”: “1-Crash”,”software_version_code”: “1.0”,”steps_to_repro”: “Step 1\r\nStep 2\r\nStep 3\r\nStep 3.1\r\nStep 3.2\r\n”, “update_user_id”: 27942,”user_name”: “Smith, John”}
Note that this response is not as long as the response given by the SOAP API. Because REST APIs typically send responses with less data and in JSON format, they require less bandwidth to use than SOAP APIs.
For specific use cases of when to use SOAP vs REST, see the table below.
When to use
SOAP Development of private APIs,
- especially for large companies: Since SOAP allows data to be transferred in a decentralized, distributed environment and has many web security mechanisms, it is ideal for enterprise solutions
- Work with stateful operations: Unlike REST API calls, SOAP API calls are stateful. This means that the server stores information about the client and uses that information in a series of requests. or chain of operations. While this requires more server resources and bandwidth, it is important if you perform repetitive or chained tasks, such as bank transfers.
- : SOAP is independent of an underlying transport protocol, so you do not need to use HTTP. Instead, you can use SMTP (Simple Mail Transfer Protocol) or JMS (Java Messaging Service) or another transport protocol, depending on your application.
.
Using an underlying transport protocol other than HTTP
When
to use REST Public API development:
- REST APIs are considered easier to use and adopt than SOAP APIs, making them ideal for building public web services. REST also lacks some built-in security features that SOAP has, but they are not necessary when working with data and utilities.
- Work with limited server resources and bandwidth: All calls to a REST API must be stateless, meaning that each interaction is independent, so each request and response provides all the information needed to complete that interaction. Because the server interprets each request as new, the server does not store information about past requests. This greatly reduces the amount of server memory required and improves performance because the server is not required to perform additional actions or retrieve past data when fulfilling a request. Also, because REST is stateless, data can be cached, which also saves server resources and bandwidth. Finally, REST APIs can use different data formats, such as JSON, which is lighter than XML. This makes them faster and more efficient than most SOAP APIs.
- Mobile app creation: Because REST is lightweight, efficient, stateless, and cacheable, it’s ideal for building mobile apps.
Deciding between SOAP and REST
There is no golden rule for creating APIs. Deciding between SOAP and REST when creating APIs depends on a variety of factors, including the programming language you use and how much time you have to build it.
