Essential API Facade Patterns: Session Management (Episode 2)

Editor's Notes

• #21: Design related- How do I design the right kind of interfaces on the server side?When should I really rely on Session Management, notwithstanding the How about authenticated sessions?How long the session should live?How much context data can be stored?Implementation relatedHow do I implement thisServer / Client In case of APIs what are the other considerations?How about persistence of session?How about scalability?
• #23: Back-endsProduct catalogueInventory ManagementPricing engine, Promotion / Tax rulesERPthe Backend stack here would beshared by multiple channels– Online ecommerce could be one of them. Hence The backend is not dedicated for the eCommerce and the problems associated with allowing such transaction flow through.
• #24: The backend is not designed for Storing client contextor managing sessionsNot enough resourceThe interfaces are stateless, by design
• #25: The eCommerce application While the backend is the master of records, the application layer does quite a lotIt manages all user centric resources…. Presentation managementManage user profile & preferences, identity management Campaign management Content management on top of the product catalogueManage eCommerce workflow & session ( provide store, shopping cart and all that Allow scale for Web Channel – The implementations of the Web Layer are quite crafty – but finally it works for the developers quite easilyThe two most basic techniques for Server Session State are using the http session and using a stateful session bean. The http session is the simple route and causes the session data to be stored by the Web server. In most cases this leads to server affinity and it can't cope with failover. Most app server vendors have implemented a shared http session capability that allows you to store http session data in a database that's available to all application servers.
• #26: So these Applications are capable of serving pages which contains state transitions ( or session embedded in the page responses)
• #29: How do we reuse this capability while exposing the APIsAll REST definitions are supposed to have resources – but the implementations provide no framework to link between resourcesThe implementations are quite crafty – but finally it works for the developers quite easily – session management is provided by the container.
• #31: How do I manage client state & session? Changing backend is toughHow do I manage HUGE VOLUMEs of such sessions?My backend does not do analytics!
• #32: We need a services layer in the middle to manage session state. So the solution will work by exposing RESTful APIs and managing stateful interactions by REST But before we go there – What is this services layer consisting of?
• #33: The services layer is a logical architecture component. It can be implemented by number of components such as Application servers, databases, API management & exposure layer, analytics and so on. The good news is that the Façade Layer does not need to rebuild all the existing capabilities. The API Service Layer is a Façade on top of the existing capabilities.
• #34: We need a Façade layer in the middle toHold the transient resources – which represents the state Expose REST APIs that allows access to these transient resource in RESTful mannerProtect the backend from the overhead of managing client stateIt is more of design principle – not so much about the actual implementation.
• #35: This gels in well with the concept ofhypermedia as the engine of stateI am not going to dig into what HATEOAS and what it is not. It is one of the principles or constraints of REST -REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.I would rather just use the most basic definition of Roy Fielding's often cited HATEOAS The next control state of an application resides in the representation of the first requested resourceEssentially every page representing a state and links in that page representing every possible transition from the current state.On a side note – why is HATEOAS difficult? Or for that matter REST difficult? Because there is no enforcement of the REST principle as a protocol or standard.
• #36: Next action can be adding the product to a cart
• #37: HATEOAS and REST is great, but,So what does it have to do with Session Management?
• #40: What are the solution benefits of this pattern of introducing a API Façade in the middle & exposing REST APIsThat manages session state as part of state transition of the resourceLet us dig a little more to understand the responsibilities of the “ API Façade “ in this particular design pattern
• #42: Let us again hypothetically take the shopping cart scenarioWhat all happens in the middle?Master system of record is somewhere out side the API Façade in the backendThe API Façade is however creating and managing the state transition of the cartIt manages the cart as a REST resourceThe stress of this diagram is the point that the stateful resources are mostly transient in nature. That is kept separate from the master records and transaction systems.
• #43: Especially the stateful transient resources --- In other words, a server should not have to retain some sort of communication state for any of the clients it communicates with beyond a single request. REST sort of mandates that state be turned into resource state or the interaction be stateless. creating these resources and managing session in the middle has benefits for the Developer What is it?REST itself
• #44: The greatest case in point for Session State in the facade is its simplicity State transition is easy – as each representation has the state transitions embedded as linksDeveloper does not have to control the stateDoes not have to maintain the entire state information and resubmit each timeLess network data to be submitted. Less programming over headCrafty APIPotentially the Developers would Love this kind of any API
• #45: For the API team the benefits are even broaderThe API Façade can be implemented as highly scalable set of infrastructure – which is generally available as part of the platform. And importantly – like mentioned before - API Façade can have state persistent behind the Façade or it can reuse existing session management infrastructure ( like an App server running in the back)The developer or the provider does not have to to code for this Also the backend is not impactedMost of the time backend legacy systems are not designed to support these types of session state management, nor it is scalable for the backend to do so. The Services Layer introduced in the middle to handle millions of calls per day is able to manage the state information for such scenarios.
• #46: The API Façade has additional capabilities to protect a session state ….Often we need a session parameter to be sent over the network…. Provides SSL offloading to secure session parametersCan provide time-expiry based sessionsCan identify replay attacks based on source and known request patternsCan disable specific clients by disabling rogue usersCan throttle illegally high request volumes so that backend is protected
• #47: There are choices – How much data to be persisted in the sessionHow much can be in-memory How much should be persisted in the DBWhat should be sticky ( as in sticky session)It is easy to implement Business rules or data mapping rules on the server side.In the context of session / state – it is often required to think about different implementations.Session at http levelSession implementation at a container level – e.g. a java session beanSession in the DBDifferent implementation approaches are possible.
• #48: API usage Analytics is a broad area. We know It is done well by introducing an API Façade in the middleWhen it comes to a session based interactions – we have an unique opportunity to track the entire session and generate analytics on progress of a workflow or a sequential transaction…Like what % of clients did progress halfway through but did not complete a transactions?
• #50: when session management would be used versus when it's not? what are the key characteristics? how do i decide?
• #51: If it is too much overhead to send back the entire context data each timeThere are two options to authenticationAuthenticate once and issue an authenticated session and continue to use that. Or. Each request will need to be authenticatedIf the interactions do not mandate a sequence of calls - or you do not require three legged Oauth kind of authentication - I would recommend sessionless interactionSometimes authentication in each request is costlyIn case of Oauth you can not avoid the authentication in a simple way. Authentication of developer and the user is concerned. You can not do the Oauth dance for every single request. It is very costly to do Oauth. So you want to reuse the authenticated token for longer than one interaction. In a way that is a session. BTW, Signed requests are much stronger than mere session ids. { Cross-site request forgeries will be mitigated with this scheme. By authenticating all requests with a shared secret we don't have any time-bound sessions or timeouts. Just fire whenever you want. The persistent shared secret is much more sensitive than a temporary session id. A cross-site scripting attack will steal the shared secret which is much worse than session hijacking. This means the scheme is less suitable for browsing sessions and more suitable for machine-to-machine communication. }Evidently signed request is a good approach over authenticated session, but too much for a phone based application to implement
• #52: Information associated with Session or “transient resource” should be minimalHandling larger chunks of session data is obviously heavy on performance
• #53: Rules to expire session must be appliedUsability vs PerformanceIf the cart has to be long lived resource – it should be persisted outside the API Façade. Only transitional state should be persisted in the API Façade.