Restful service stands for representational
state transfer, so it is stateless, the idea is back-end service
doesn't manage session so it can focus on its main job: to provide data
and process data. In this way the load of session management is
amortized across all the clients, so the back-end service can be easily
scaled up and serve millions of requests with not overhead in session
management which creates thread contention.
At any particular time, a client can either be in transition between application states or "at rest". A client in a rest state is able to interact with its user, but creates no load and consumes no per-client storage on the set of servers or on the network.
But many of the application needs user
session management to allow authorized and authenticated access to
resource such as user data and order process.
- basic access authentication and digest access authentication. user/pass is sending along every request. Obviously it has to be done on HTTPS using TLS.
- OAuth based authorization, Many of the popular Restful APIs are done by this. Every Restful client has a secret key, and once server authenticates the user/pass, a token is returned, Restful client needs to store the token locally and send every request along with secret key and token. Auth token should work the same as HTTP session id. The server has to store somewhere such as a table with a timestamp.
- If this is browser-based client, then a slight different version from the No. 2 is to use HTTP header to send three piece of info: user_id, expiration_date and a HMAC hash og user_id+expiration_date+secret_key. ,
- Another different way to do it is actually let server creates session, so browser based client will send each Ajax request with cookie header. This is probably most non-useful approach. ;)
No comments:
Post a Comment