Stay Connected and Keep Current

Sessionless APIs

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.

Additional Resources

[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 product catalog list of 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.