0

As restful service stateless, it don't maintain any interaction of user, so i want to know if multiple user accessing same restful service, then how restful service identify which user interact with which method ? and is it possible to make restful service as stateful ?

Sangram Badi
  • 3,594
  • 6
  • 30
  • 59
  • Most systems use cookies or other data passed in the request to identify the user. A very simple implementation is e.g. Basic Authentication. – Smutje Nov 11 '16 at 07:45
  • 2
    Possible duplicate of [If REST applications are supposed to be stateless, how do you manage sessions?](http://stackoverflow.com/questions/3105296/if-rest-applications-are-supposed-to-be-stateless-how-do-you-manage-sessions) – dieter Nov 11 '16 at 07:47
  • So is it possible to make it as stateful ? – Sangram Badi Nov 11 '16 at 07:54
  • 2
    The key in REST is that the state is contained in the request. See the linked question for more details. – Smutje Nov 11 '16 at 07:55

3 Answers3

1

Which user:

By using a shared secret (a line of chars), created on the server, and returned with every next request.

It's "saved" in a cookie and returned by the client, using either a cookie or a HTTP(S) header.

Which method:

This depends on the framework you use. But eventually it comes down to mapping URI's to your methods.

and is it possible to make restful service as stateful ?

You can make stateful apps, then they are not restful. A restful app is stateless. That's the definition, so you can make stateful apps, but you can never create a stateful rest-app, as rest is stateless.

Jeroen van Dijk-Jun
  • 959
  • 9
  • 21
  • if we make restful service to stateful then restful service will not be restful, it means we should not make restful service as stateful, right ? – Sangram Badi Nov 11 '16 at 09:50
  • It's a definition thing: if we make restful service to stateful, it's not restful anymore. – Jeroen van Dijk-Jun Nov 11 '16 at 10:03
  • in cookie which data need to store to identify a user? if it is a login less application – Sangram Badi Nov 11 '16 at 10:07
  • 1
    It doesn't matter if you use a login mechanism. You can always create a cookie, together with its unique identifier. This object and its identifier is stored in a big map on the server (along with the other cookie-identifiers), The clients browser saves the identifier (along with all other cookie-id's from other domains). Within that session object connected to that identifier you can store and retrieve all what is serializable on the server. I hope you use a framework, because then this is all you need to know. :-) – Jeroen van Dijk-Jun Nov 11 '16 at 10:11
0

According to my point of view Restful web service make as a stateless.it's architectural style which have set of constraints and properties so stateless is its properties we cannot change its properties so its doesn't mean that restful service is stateful .

we can mapped URI's to your method then restful know which user is calling which method.

Deepak.kumar
  • 1
0

tl;dr

The client must store its own session state and pass it around to the server in each request.

The stateless constraint

The stateless constraint of the REST architectural style is define as follows:

5.1.3 Stateless

[...] each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client. [...]

Authentication

If the client requests protected resources that require authentication, every request must contain all necessary data to be properly authenticated/authorized. See this quote from the RFC 7235:

HTTP authentication is presumed to be stateless: all of the information necessary to authenticate a request MUST be provided in the request, rather than be dependent on the server remembering prior requests.

And authentication data should belong to the standard HTTP Authorization header. From the RFC 7235:

4.2. Authorization

The Authorization header field allows a user agent to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 (Unauthorized) response. Its value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested. [...]

The name of this HTTP header is unfortunate because it carries authentication instead of authorization data.

For authentication, you could use the Basic HTTP Authentication scheme, which transmits credentials as username and password pairs, encoded using Base64:

Authorization: Basic <credentials>

If you don't want to send the username and password in each request, the username and password could be exchanged for a token (such as JWT) that is sent in each request. A JWT token can contain the username, an expiration date and any other metadata that may be relevant for your application:

Authorization: Bearer <token>

See this answer for more details.

Community
  • 1
  • 1
cassiomolin
  • 101,346
  • 24
  • 214
  • 283