- 4 New Ways We’re Changing the Way You Do Car Shopping
- A New Way to Book Lodging Made Easier
- Content Services for Lodging Migration Guide
- Content Services for Lodging Deep Dive Part 3: Checking Prices
- Content Services for Lodging Deep Dive Part 2: Getting Details
- Content Services for Lodging Deep Dive Part 1: Getting Availability
- Looking at Lodging APIs Part 2: What You Can Do with Them and Looking Forward
- Looking at Lodging APIs Part 1: Why We Built Them and How You Might See Them
- 6 Powerful Ways Content Services for Lodging Will Change How You Access Hotels Today
- October 2019
- September 2019
- July 2019
- June 2019
- May 2019
- March 2019
- December 2018
- November 2018
- October 2018
- September 2018
- August 2018
- July 2018
- June 2018
- May 2018
- March 2018
- January 2018
- November 2017
- October 2017
- August 2017
- July 2017
- June 2017
- May 2017
- March 2017
- January 2017
- December 2016
- November 2016
- September 2016
- July 2016
- June 2016
- May 2016
- April 2016
- March 2016
- February 2016
- December 2015
- October 2015
- September 2015
- August 2015
- July 2015
- June 2015
- May 2015
- April 2015
- March 2015
- February 2015
Share this page
by Ken Tabor
A few weeks ago, we met with software developers to offer them advice on using our Sabre APIs (Sabre Web Services) in their application. While reviewing how to access travel content, my teammate, Gonzalo Jorge, mentioned using our sessionless APIs.
They were surprised by hearing about sessionless and interested in knowing how they work. Using this category of APIs could have saved them writing a sizable amount of session management code to interact with our services. Even still, they can consider how to bring in the new APIs and evolve their architecture to deprecate obsoleted session management code.
What I took away from our meeting is that we should resurface this useful topic. I know developers spend their days getting the code working to deliver functions. There’s not a lot of time to catch up on researching new technology.
This article will help you jump-start your understanding of the benefits of using sessionless APIs.
About Sessionless APIs
Traditionally, Sabre APIs have required a session to operate. Developers first authenticate with Sabre and create a session to work within. Subsequent API calls refer to that session identifier one at a time. Sessions can be used as much as you like, but you must consider that after fifteen minutes of inactivity the session will automatically close.
You can see that sessions require developers to write a section of code devoted to session management. Not only for calling an individual API but for calling multiple APIs at once. How can multiple APIs be called? Because customers are allocated fifty sessions when they sign up. Most applications maintain its own collection of open sessions and allocate them to service calls as needed. Extra sessions may be purchased if more than fifty are needed.
Once you’ve made all your service calls, it’s important to close the session. Sessions may be refreshed for the case of an application needing a high-volume of transactions. Creating a session takes a certain amount of time, and although it’s short, it does add up as latency. Many customers have written refreshing into their session management code as an optimization technique for connecting to Sabre.
Another need behind application-level session management comes from a particular activity. Sabre’s system has an automated process running every weekend. That process does the work to close all open sessions. It’s a clean-up job with the goal of keeping the system running efficiently.
We saw the session management architectural design pattern emerging in our customers. We know this type of code takes weeks to build up properly, and we decided on a plan to improve the developer experience. About three years ago we enabled sessionless APIs.
Session-based APIs still exist and will for some time to come. One of the goals for new versions of APIs is offering a sessionless-version. This makes them easier for developers to use.
Why Use a Sessionless API
Many of the latest APIs don’t require a session to operate. How does that work? They are so-called sessionless APIs. Instead of a session, a token is returned when an application securely authenticates with Sabre. Including this security token with subsequent calls to Sabre, web services prove authorization and the expected response is returned.
Sessionless tokens have less maintenance as well. Tokens are kept alive longer than sessions – seven full days – and no concern regarding inactive timeouts. Tokens are not affected by the automated, global close-session process scheduled over the weekend.
There is no limit to calling services with the token. That includes applications that have high-transaction processing or perform concurrent requests. Building up a user screen composed of multiple API calls issued at once can feel more responsive to a user as parts of the screen are built up simultaneously from API responses.
Note: there may be call limits put in place based on your individual service agreement.
What types of APIs are sessionless
If your history includes using session-based APIs you’ll wonder which sessionless ones are available today. Here are the general guidelines:
- All REST APIs are sessionless
- Some SOAP APIs are sessionless
Determining if the API you want to use is session-enabled, or token-enabled, is simple. When you review the particular API’s documentation page you’ll find the section entitled “API Information.” One of the attributes listed is “Authentication.” You’ll see there are two possible values:
- “Session Token”
- “Sessionless Token”
Here is an example taken from the Sabre Dev Studio documentation site:
Experiment with the sessionless Sabre APIs that you’re interested in using as time permits. Current they’re available to all existing customers. There’s no additional contracts or provisioning required.
[How to Get a Token] – An introduction to using the modern, sessionless APIs. These are the new ones that take security tokens. Find step-by-step instructions on how to approach them.
[Learning About Sabre Tokens] – A complete overview of how to use APIs with session tokens as well as those that are sessionless. Explains the weekend system maintenance activities.
[Session Management] – A review of the APIs used for managing session connections with classic APIs.
Session Tech in Review
Here’s another way to think of the material presented in this article.
A Sessionless World
After reading this article you may want to conduct code reviews of the Sabre APIs that your software application uses. Do any of the APIs have sessionless versions? Consider converting to them.
If all of the services you’re using are sessionless, and your app has session management logic, you might be able to refactor it out of your codebase.
Ideally, we want to move to a world of completely sessionless APIs. We have the technology in production, we’re offering many such APIs now, and we have a roadmap to evolve others. Watch our blog for updates.