REST vs. SOAP: A Bottom-Line Analysis

by Leah Tucker


There used to be a lot of debate around SOAP versus REST—“there’s no right answer” or “it’s all about priorities, personal preference.” It’s been about 15 years since REST was initially proposed by Roy Thomas Fielding (wiki) and a lot of the articles that say REST is the “new kid on the block” and “ever-gaining in popularity” are ten-plus years old.

I asked developers around Sabre to share their likes and dislikes of REST and SOAP. Pretty much everyone had an opinion and there were many misconceptions about both, especially REST. However, I eventually got to the heart of the issue and was most struck with the following:

“Overall discussion on REST vs. SOAP is hard because there are many misconceptions around REST. Here is a doctoral dissertation describing REST by REST inventor Roy T. Fielding and a blog article of his musings (also look at the comments). ’” – Wojciech Granicki

“REST is like a small city’s bi-law. REST is like: ‘hey, what would you like? [shrug] Here’s what I’ll give ya.’ SOAP is like a congressional bill. SOAP is like: ‘I don’t have to talk to you, I’ll just code to specification because I have a specification.’” – David Browne

In essence, what all of this means is that people have lost sight of what REST truly is because many REST APIs don’t fit the true REST model.  (I, too, have my doubts about the true REST concept.) SOAP has a particular way it wants you to do things and the metaphoric forms to fill out. REST has a city council-way of doing things. That’s why I think it appeals to developers, and contrary to a lot of articles out there, there is a right answer to the REST versus SOAP debate, but it’s not what you might think.

Here goes (a few basics)…


REST (Representational State Transfer) is an architectural style for building client-server applications. In simple terms, this means the URL is a representation of an object. Depending on the API, you can create, read, update or delete the contents of that object in the URL. Here’s a quick recap of what makes up a request:

  1. (First off, get an access token and put it in your header.)
  2. Use the HTTP method to POST (Create), GET (Read), PUT (Update) or DELETE (Dispose) etc. (a.k.a., “CRUD”) an object. (This is GET in our example.)
  3. Use the domain you would like to use to access the object.
  4. Use the endpoint to “CRUD” the object.
  5. Use the request parameters or variables to filter the object by a particular value.
  6. Use the standard protocol for REST APIs. (This is HTTP/1.1.)
  7. Format: GET https://{domain}/endpoint/?parameter=value HTTP/1.1

The following REST example demonstrates a Lead Price Calendar API request for the lowest fares from JFK to LAX with a max fare of $280 and a departure date of April 16. The response is one fare.



Why we like REST

  • It uses standard HTTP methods in a unique URL
  • REST “reads” can be cached (making it more scalable)
  • It is loved by the broader developer community
  • It is generally more lightweight in an ideal world
  • We like it for mobile apps
  • HATEOAS best practices intrigue us
  • It works well with both JSON and XML
  • More JavaScript-based UI frameworks support REST


SOAP is a protocol used to exchange XML-based messages between systems.  SOAP is strict in terms of how the data is exchanged (being a protocol), so there’s no simple metaphor we can use to describe it. In simple terms, it’s oriented to exposing operations/logic using “CRUD” with the tool of your choice.

Oftentimes SOAP is used in conjunction with WSDLs.  WSDLs tell programmers how to create XML-based messages, where to send them, and what to expect in terms of responses. Here’s a high-level, completely oversimplified recap of what that may look like:

  1. (First off, get a token and put it in the right place in your XML header).
  2. Download the WSDL
  3. Use the tool of your choice (e.g. SoapUI) to build an XML request using (or conforming to) the WSDL.
  4. Establish any prerequisite state or transaction context (if applicable).
  5. POST a request to the service.

Note: An XML request can be sent either as an attachment or within the payload.

The following SOAP example demonstrates a Get Flight Details API request to retrieve flight details for a specific flight number. The response is a list of details about the flight, including gate, departure time and baggage claim.



Why we like SOAP

  • It has additional security methods (e.g. WS-Security, atomic database transactions, built-in error handling)
  • It’s considered to be a better-suited standard for stateful transactions
  • It is W3C standardized
  • It has out-of-the box integration for tools (e.g. SoapUI)
  • It’s easy to convert the request/response into another language
  • It has a lot of standards around how to do secure messaging (exchange)
  • The security features are built into the tools and protocol
  • You can do some pretty cool stuff with the WSDL (like auto-generating and validating requests and responses)
  • It supports comments and embedded documentation

Here’s the thing

First off, before you start stressin’ over which to choose, know this—the decision might have already been made for you. Only a handful of APIs support both SOAP and REST and seldom can all members of a development team code equally well in both. It’s usually either/or—depends on your developer skillset.

Second, if you do have a choice, what’s most important isn’t necessarily the protocol—it’s the simplicity of the API. How straightforward is the documentation? If a new developer joins your team, how much would you be forced to explain to get them up to speed? Look at the data structure. Is it intuitive?

In summary, the consensus here at Sabre is this—if you have a choice, go with the simplest, most straightforward API, not (necessarily) the protocol. The most straightforward API will be much simpler to implement into an existing application, easier on your team and easier to scale over the long-term.

“The more organized the team, the easier an API is to use, the more intuitive the data structure, the better the documentation—the less complicated the API.” – David Browne

A few more data bits

  • For further details on REST and what REST really is, check out the doctoral dissertation we linked to at the start of the blog by REST inventor Roy T. Fielding.
  • The acronym SOAP no longer stands for Simple Object Access Protocol as of the 1.2 specification from the W3C organization. It is now just the name of the specification.
  • About SOAP’s built-in error handling—if there’s a problem with your request, the response body or the header contains error information to fix the problem. In an ideal world, the header is mostly supposed to contain the error…mostly.
  • For REST, when specifying a URL in code, any special characters (characters other than letters and numbers) need to be encoded. For example, a space character is encoded as %20.

Some stuff about us

Sabre Dev Studio provides the building blocks that enable customers to build world class travel applications with our leading portfolio of Sabre APIs.

Sabre APIs can be consumed using SOAP or REST API protocols and very often our developers use a combination of both. Therefore we will continue to heavily invest in both, and continue advancing our portfolio across both technologies.

If you would like to start exploring our REST APIs, send your first requests for free by registering with API Explorer.

About Leah Tucker

Leah Tucker is the Lead Technical Writer for Sabre REST APIs. Prior to technical writing, she worked in a number of roles, including front-end web development and UX, web and content standards, government/media relations and copyediting. Leah holds a BA in Communication and is also a part-time student where she takes various classes for fun, like chemistry.

Leave a Reply

Your email address will not be published. Required fields are marked *