The meaning of 'stateless' in rest and Http
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
When I read the documents about what the REST is, one of what they always say is that REST api should be stateless. Here, I feel a bit awkward, since just plain HTTP is also stateless.
Since REST can be said it's a special architecture using HTTP protocols, it seems redundant to say that REST should be stateless.
Does the word 'stateless' means the same thing in both REST and HTTP?
If not please tell me the difference
I'm not asking the meaning of stateless in http, but difference of stateless in rest and http
rest http stateless
add a comment |
When I read the documents about what the REST is, one of what they always say is that REST api should be stateless. Here, I feel a bit awkward, since just plain HTTP is also stateless.
Since REST can be said it's a special architecture using HTTP protocols, it seems redundant to say that REST should be stateless.
Does the word 'stateless' means the same thing in both REST and HTTP?
If not please tell me the difference
I'm not asking the meaning of stateless in http, but difference of stateless in rest and http
rest http stateless
Possible duplicate of Why is it said that "HTTP is a stateless protocol"?
– Rafael
Jan 3 at 5:24
@Rafael I'm not asking the meaning of stateless in http, but difference of stateless in rest and http
– Rhee
Jan 3 at 5:32
add a comment |
When I read the documents about what the REST is, one of what they always say is that REST api should be stateless. Here, I feel a bit awkward, since just plain HTTP is also stateless.
Since REST can be said it's a special architecture using HTTP protocols, it seems redundant to say that REST should be stateless.
Does the word 'stateless' means the same thing in both REST and HTTP?
If not please tell me the difference
I'm not asking the meaning of stateless in http, but difference of stateless in rest and http
rest http stateless
When I read the documents about what the REST is, one of what they always say is that REST api should be stateless. Here, I feel a bit awkward, since just plain HTTP is also stateless.
Since REST can be said it's a special architecture using HTTP protocols, it seems redundant to say that REST should be stateless.
Does the word 'stateless' means the same thing in both REST and HTTP?
If not please tell me the difference
I'm not asking the meaning of stateless in http, but difference of stateless in rest and http
rest http stateless
rest http stateless
edited Jan 3 at 5:28
Rhee
asked Jan 3 at 5:18


RheeRhee
13719
13719
Possible duplicate of Why is it said that "HTTP is a stateless protocol"?
– Rafael
Jan 3 at 5:24
@Rafael I'm not asking the meaning of stateless in http, but difference of stateless in rest and http
– Rhee
Jan 3 at 5:32
add a comment |
Possible duplicate of Why is it said that "HTTP is a stateless protocol"?
– Rafael
Jan 3 at 5:24
@Rafael I'm not asking the meaning of stateless in http, but difference of stateless in rest and http
– Rhee
Jan 3 at 5:32
Possible duplicate of Why is it said that "HTTP is a stateless protocol"?
– Rafael
Jan 3 at 5:24
Possible duplicate of Why is it said that "HTTP is a stateless protocol"?
– Rafael
Jan 3 at 5:24
@Rafael I'm not asking the meaning of stateless in http, but difference of stateless in rest and http
– Rhee
Jan 3 at 5:32
@Rafael I'm not asking the meaning of stateless in http, but difference of stateless in rest and http
– Rhee
Jan 3 at 5:32
add a comment |
3 Answers
3
active
oldest
votes
Does the word 'stateless' means the same thing in both REST and HTTP?
Yes.
The reason that they are the same is that HTTP is a consequence of REST.
Since 1994, the REST architectural style has been used to guide the design and development of the architecture for the modern Web -- Fielding, 2000.
Prior to his dissertation, Fielding was an author of RFC 2068 and RFC 2616.
Just for clarification, could you tell me what '"the principles that are now called REST were refined through Fielding's work on HTTP.' means?
Section One of Reflections on the REST Architectural Style includes a timeline: the first implementations of HTTP were in 1990-91, Fielding started participating in 1993. During the specification process (RFC 1945, RFC 2068, RFC 2616) Fielding developed an "HTTP Object Model" that later came to be understood as the "REST Architectural Style".
The first edition of REST was developed between October 1994 and August 1995, primarily as a means for communicating Web concepts as we wrote the HTTP/1.0 specification and the initial HTTP/1.1 proposal. -- Fielding
Which is to say, the ideas of REST evolved in parallel with the standardization of HTTP, to serve as an oracle: how can we evaluate whether a proposal will damage or destroy the important properties of the web?
Section 6.3.4 of the thesis describes the consequences of some mismatches that were standardized.
3
HTTP is a consequence of REST deserves better explanation than you've given, since Fielding's work on HTTP predates the dissertation in which he defined REST. It might be clearer to say something like "the principles that are now called REST were refined through Fielding's work on HTTP."
– Caleb
Jan 3 at 14:27
@Caleb Thanks Caleb for your additional explanation. Just for clarification, could you tell me what '"the principles that are now called REST were refined through Fielding's work on HTTP.' means? You mean, Fielding has the idea of statelessness, but while working on HTTP, it got better, and after then HTTP was announced, he announced REST?
– Rhee
Jan 4 at 9:44
@Rhee There's a quote from Fielding on the Wikipedia entry on REST where he explains that while developing the HTTP standard, he had to respond to comments from 500+ developers. He said: "That process honed my model down to a core set of principles, properties, and constraints that are now called REST."
– Caleb
Jan 4 at 12:58
add a comment |
Stateless in HTTP terms means that each request has no knowledge of any prior request, i.e, there is no built-in mechanism in HTTP to track who is making requests and the effects of those requests.
In terms of RESTful services, it means that each request doesn't rely on state, e.g., saved client info, to fulfill a request -- all information needed to fulfill a request is enclosed in the request message (the CRUD operation, resource in question, auth tokens, app platform identification, etc.).
This means that your RESTful API should be guarded by a layered architecture that governs authentication, session management, and other non-RESTful operations.
In this context, both RESTful services and HTTP should operate under the same constraints: statelessness (as defined above).
It may seem intuitive to design a REST API like this, but you'd be surprised of the close-couplings found at the core of many REST services:
GET /users/:id
if authenticated and authorized //not stateless
send User resource
To combat this, most HTTP frameworks provide middleware layers.
Helpful REST-design questions:
- What is idempotency in HTTP methods?
add a comment |
REST stands for Representational State Transfer which means that the state is representational. Request tracking mechanism or Session is not preserved on the api server. The state of a request may be transferred to other api servers.
Moreover the convention like GET /users/:id states that each resource has a identification mechanism in built in the url thus there is no need to track the resources in a request as the URL itself contains the client resource request information eg: GET /users/1, PUT /users/1.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54016721%2fthe-meaning-of-stateless-in-rest-and-http%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Does the word 'stateless' means the same thing in both REST and HTTP?
Yes.
The reason that they are the same is that HTTP is a consequence of REST.
Since 1994, the REST architectural style has been used to guide the design and development of the architecture for the modern Web -- Fielding, 2000.
Prior to his dissertation, Fielding was an author of RFC 2068 and RFC 2616.
Just for clarification, could you tell me what '"the principles that are now called REST were refined through Fielding's work on HTTP.' means?
Section One of Reflections on the REST Architectural Style includes a timeline: the first implementations of HTTP were in 1990-91, Fielding started participating in 1993. During the specification process (RFC 1945, RFC 2068, RFC 2616) Fielding developed an "HTTP Object Model" that later came to be understood as the "REST Architectural Style".
The first edition of REST was developed between October 1994 and August 1995, primarily as a means for communicating Web concepts as we wrote the HTTP/1.0 specification and the initial HTTP/1.1 proposal. -- Fielding
Which is to say, the ideas of REST evolved in parallel with the standardization of HTTP, to serve as an oracle: how can we evaluate whether a proposal will damage or destroy the important properties of the web?
Section 6.3.4 of the thesis describes the consequences of some mismatches that were standardized.
3
HTTP is a consequence of REST deserves better explanation than you've given, since Fielding's work on HTTP predates the dissertation in which he defined REST. It might be clearer to say something like "the principles that are now called REST were refined through Fielding's work on HTTP."
– Caleb
Jan 3 at 14:27
@Caleb Thanks Caleb for your additional explanation. Just for clarification, could you tell me what '"the principles that are now called REST were refined through Fielding's work on HTTP.' means? You mean, Fielding has the idea of statelessness, but while working on HTTP, it got better, and after then HTTP was announced, he announced REST?
– Rhee
Jan 4 at 9:44
@Rhee There's a quote from Fielding on the Wikipedia entry on REST where he explains that while developing the HTTP standard, he had to respond to comments from 500+ developers. He said: "That process honed my model down to a core set of principles, properties, and constraints that are now called REST."
– Caleb
Jan 4 at 12:58
add a comment |
Does the word 'stateless' means the same thing in both REST and HTTP?
Yes.
The reason that they are the same is that HTTP is a consequence of REST.
Since 1994, the REST architectural style has been used to guide the design and development of the architecture for the modern Web -- Fielding, 2000.
Prior to his dissertation, Fielding was an author of RFC 2068 and RFC 2616.
Just for clarification, could you tell me what '"the principles that are now called REST were refined through Fielding's work on HTTP.' means?
Section One of Reflections on the REST Architectural Style includes a timeline: the first implementations of HTTP were in 1990-91, Fielding started participating in 1993. During the specification process (RFC 1945, RFC 2068, RFC 2616) Fielding developed an "HTTP Object Model" that later came to be understood as the "REST Architectural Style".
The first edition of REST was developed between October 1994 and August 1995, primarily as a means for communicating Web concepts as we wrote the HTTP/1.0 specification and the initial HTTP/1.1 proposal. -- Fielding
Which is to say, the ideas of REST evolved in parallel with the standardization of HTTP, to serve as an oracle: how can we evaluate whether a proposal will damage or destroy the important properties of the web?
Section 6.3.4 of the thesis describes the consequences of some mismatches that were standardized.
3
HTTP is a consequence of REST deserves better explanation than you've given, since Fielding's work on HTTP predates the dissertation in which he defined REST. It might be clearer to say something like "the principles that are now called REST were refined through Fielding's work on HTTP."
– Caleb
Jan 3 at 14:27
@Caleb Thanks Caleb for your additional explanation. Just for clarification, could you tell me what '"the principles that are now called REST were refined through Fielding's work on HTTP.' means? You mean, Fielding has the idea of statelessness, but while working on HTTP, it got better, and after then HTTP was announced, he announced REST?
– Rhee
Jan 4 at 9:44
@Rhee There's a quote from Fielding on the Wikipedia entry on REST where he explains that while developing the HTTP standard, he had to respond to comments from 500+ developers. He said: "That process honed my model down to a core set of principles, properties, and constraints that are now called REST."
– Caleb
Jan 4 at 12:58
add a comment |
Does the word 'stateless' means the same thing in both REST and HTTP?
Yes.
The reason that they are the same is that HTTP is a consequence of REST.
Since 1994, the REST architectural style has been used to guide the design and development of the architecture for the modern Web -- Fielding, 2000.
Prior to his dissertation, Fielding was an author of RFC 2068 and RFC 2616.
Just for clarification, could you tell me what '"the principles that are now called REST were refined through Fielding's work on HTTP.' means?
Section One of Reflections on the REST Architectural Style includes a timeline: the first implementations of HTTP were in 1990-91, Fielding started participating in 1993. During the specification process (RFC 1945, RFC 2068, RFC 2616) Fielding developed an "HTTP Object Model" that later came to be understood as the "REST Architectural Style".
The first edition of REST was developed between October 1994 and August 1995, primarily as a means for communicating Web concepts as we wrote the HTTP/1.0 specification and the initial HTTP/1.1 proposal. -- Fielding
Which is to say, the ideas of REST evolved in parallel with the standardization of HTTP, to serve as an oracle: how can we evaluate whether a proposal will damage or destroy the important properties of the web?
Section 6.3.4 of the thesis describes the consequences of some mismatches that were standardized.
Does the word 'stateless' means the same thing in both REST and HTTP?
Yes.
The reason that they are the same is that HTTP is a consequence of REST.
Since 1994, the REST architectural style has been used to guide the design and development of the architecture for the modern Web -- Fielding, 2000.
Prior to his dissertation, Fielding was an author of RFC 2068 and RFC 2616.
Just for clarification, could you tell me what '"the principles that are now called REST were refined through Fielding's work on HTTP.' means?
Section One of Reflections on the REST Architectural Style includes a timeline: the first implementations of HTTP were in 1990-91, Fielding started participating in 1993. During the specification process (RFC 1945, RFC 2068, RFC 2616) Fielding developed an "HTTP Object Model" that later came to be understood as the "REST Architectural Style".
The first edition of REST was developed between October 1994 and August 1995, primarily as a means for communicating Web concepts as we wrote the HTTP/1.0 specification and the initial HTTP/1.1 proposal. -- Fielding
Which is to say, the ideas of REST evolved in parallel with the standardization of HTTP, to serve as an oracle: how can we evaluate whether a proposal will damage or destroy the important properties of the web?
Section 6.3.4 of the thesis describes the consequences of some mismatches that were standardized.
edited Jan 4 at 12:28
answered Jan 3 at 14:02
VoiceOfUnreasonVoiceOfUnreason
21.8k22251
21.8k22251
3
HTTP is a consequence of REST deserves better explanation than you've given, since Fielding's work on HTTP predates the dissertation in which he defined REST. It might be clearer to say something like "the principles that are now called REST were refined through Fielding's work on HTTP."
– Caleb
Jan 3 at 14:27
@Caleb Thanks Caleb for your additional explanation. Just for clarification, could you tell me what '"the principles that are now called REST were refined through Fielding's work on HTTP.' means? You mean, Fielding has the idea of statelessness, but while working on HTTP, it got better, and after then HTTP was announced, he announced REST?
– Rhee
Jan 4 at 9:44
@Rhee There's a quote from Fielding on the Wikipedia entry on REST where he explains that while developing the HTTP standard, he had to respond to comments from 500+ developers. He said: "That process honed my model down to a core set of principles, properties, and constraints that are now called REST."
– Caleb
Jan 4 at 12:58
add a comment |
3
HTTP is a consequence of REST deserves better explanation than you've given, since Fielding's work on HTTP predates the dissertation in which he defined REST. It might be clearer to say something like "the principles that are now called REST were refined through Fielding's work on HTTP."
– Caleb
Jan 3 at 14:27
@Caleb Thanks Caleb for your additional explanation. Just for clarification, could you tell me what '"the principles that are now called REST were refined through Fielding's work on HTTP.' means? You mean, Fielding has the idea of statelessness, but while working on HTTP, it got better, and after then HTTP was announced, he announced REST?
– Rhee
Jan 4 at 9:44
@Rhee There's a quote from Fielding on the Wikipedia entry on REST where he explains that while developing the HTTP standard, he had to respond to comments from 500+ developers. He said: "That process honed my model down to a core set of principles, properties, and constraints that are now called REST."
– Caleb
Jan 4 at 12:58
3
3
HTTP is a consequence of REST deserves better explanation than you've given, since Fielding's work on HTTP predates the dissertation in which he defined REST. It might be clearer to say something like "the principles that are now called REST were refined through Fielding's work on HTTP."
– Caleb
Jan 3 at 14:27
HTTP is a consequence of REST deserves better explanation than you've given, since Fielding's work on HTTP predates the dissertation in which he defined REST. It might be clearer to say something like "the principles that are now called REST were refined through Fielding's work on HTTP."
– Caleb
Jan 3 at 14:27
@Caleb Thanks Caleb for your additional explanation. Just for clarification, could you tell me what '"the principles that are now called REST were refined through Fielding's work on HTTP.' means? You mean, Fielding has the idea of statelessness, but while working on HTTP, it got better, and after then HTTP was announced, he announced REST?
– Rhee
Jan 4 at 9:44
@Caleb Thanks Caleb for your additional explanation. Just for clarification, could you tell me what '"the principles that are now called REST were refined through Fielding's work on HTTP.' means? You mean, Fielding has the idea of statelessness, but while working on HTTP, it got better, and after then HTTP was announced, he announced REST?
– Rhee
Jan 4 at 9:44
@Rhee There's a quote from Fielding on the Wikipedia entry on REST where he explains that while developing the HTTP standard, he had to respond to comments from 500+ developers. He said: "That process honed my model down to a core set of principles, properties, and constraints that are now called REST."
– Caleb
Jan 4 at 12:58
@Rhee There's a quote from Fielding on the Wikipedia entry on REST where he explains that while developing the HTTP standard, he had to respond to comments from 500+ developers. He said: "That process honed my model down to a core set of principles, properties, and constraints that are now called REST."
– Caleb
Jan 4 at 12:58
add a comment |
Stateless in HTTP terms means that each request has no knowledge of any prior request, i.e, there is no built-in mechanism in HTTP to track who is making requests and the effects of those requests.
In terms of RESTful services, it means that each request doesn't rely on state, e.g., saved client info, to fulfill a request -- all information needed to fulfill a request is enclosed in the request message (the CRUD operation, resource in question, auth tokens, app platform identification, etc.).
This means that your RESTful API should be guarded by a layered architecture that governs authentication, session management, and other non-RESTful operations.
In this context, both RESTful services and HTTP should operate under the same constraints: statelessness (as defined above).
It may seem intuitive to design a REST API like this, but you'd be surprised of the close-couplings found at the core of many REST services:
GET /users/:id
if authenticated and authorized //not stateless
send User resource
To combat this, most HTTP frameworks provide middleware layers.
Helpful REST-design questions:
- What is idempotency in HTTP methods?
add a comment |
Stateless in HTTP terms means that each request has no knowledge of any prior request, i.e, there is no built-in mechanism in HTTP to track who is making requests and the effects of those requests.
In terms of RESTful services, it means that each request doesn't rely on state, e.g., saved client info, to fulfill a request -- all information needed to fulfill a request is enclosed in the request message (the CRUD operation, resource in question, auth tokens, app platform identification, etc.).
This means that your RESTful API should be guarded by a layered architecture that governs authentication, session management, and other non-RESTful operations.
In this context, both RESTful services and HTTP should operate under the same constraints: statelessness (as defined above).
It may seem intuitive to design a REST API like this, but you'd be surprised of the close-couplings found at the core of many REST services:
GET /users/:id
if authenticated and authorized //not stateless
send User resource
To combat this, most HTTP frameworks provide middleware layers.
Helpful REST-design questions:
- What is idempotency in HTTP methods?
add a comment |
Stateless in HTTP terms means that each request has no knowledge of any prior request, i.e, there is no built-in mechanism in HTTP to track who is making requests and the effects of those requests.
In terms of RESTful services, it means that each request doesn't rely on state, e.g., saved client info, to fulfill a request -- all information needed to fulfill a request is enclosed in the request message (the CRUD operation, resource in question, auth tokens, app platform identification, etc.).
This means that your RESTful API should be guarded by a layered architecture that governs authentication, session management, and other non-RESTful operations.
In this context, both RESTful services and HTTP should operate under the same constraints: statelessness (as defined above).
It may seem intuitive to design a REST API like this, but you'd be surprised of the close-couplings found at the core of many REST services:
GET /users/:id
if authenticated and authorized //not stateless
send User resource
To combat this, most HTTP frameworks provide middleware layers.
Helpful REST-design questions:
- What is idempotency in HTTP methods?
Stateless in HTTP terms means that each request has no knowledge of any prior request, i.e, there is no built-in mechanism in HTTP to track who is making requests and the effects of those requests.
In terms of RESTful services, it means that each request doesn't rely on state, e.g., saved client info, to fulfill a request -- all information needed to fulfill a request is enclosed in the request message (the CRUD operation, resource in question, auth tokens, app platform identification, etc.).
This means that your RESTful API should be guarded by a layered architecture that governs authentication, session management, and other non-RESTful operations.
In this context, both RESTful services and HTTP should operate under the same constraints: statelessness (as defined above).
It may seem intuitive to design a REST API like this, but you'd be surprised of the close-couplings found at the core of many REST services:
GET /users/:id
if authenticated and authorized //not stateless
send User resource
To combat this, most HTTP frameworks provide middleware layers.
Helpful REST-design questions:
- What is idempotency in HTTP methods?
edited Jan 3 at 16:05
answered Jan 3 at 5:47


RafaelRafael
4,952102339
4,952102339
add a comment |
add a comment |
REST stands for Representational State Transfer which means that the state is representational. Request tracking mechanism or Session is not preserved on the api server. The state of a request may be transferred to other api servers.
Moreover the convention like GET /users/:id states that each resource has a identification mechanism in built in the url thus there is no need to track the resources in a request as the URL itself contains the client resource request information eg: GET /users/1, PUT /users/1.
add a comment |
REST stands for Representational State Transfer which means that the state is representational. Request tracking mechanism or Session is not preserved on the api server. The state of a request may be transferred to other api servers.
Moreover the convention like GET /users/:id states that each resource has a identification mechanism in built in the url thus there is no need to track the resources in a request as the URL itself contains the client resource request information eg: GET /users/1, PUT /users/1.
add a comment |
REST stands for Representational State Transfer which means that the state is representational. Request tracking mechanism or Session is not preserved on the api server. The state of a request may be transferred to other api servers.
Moreover the convention like GET /users/:id states that each resource has a identification mechanism in built in the url thus there is no need to track the resources in a request as the URL itself contains the client resource request information eg: GET /users/1, PUT /users/1.
REST stands for Representational State Transfer which means that the state is representational. Request tracking mechanism or Session is not preserved on the api server. The state of a request may be transferred to other api servers.
Moreover the convention like GET /users/:id states that each resource has a identification mechanism in built in the url thus there is no need to track the resources in a request as the URL itself contains the client resource request information eg: GET /users/1, PUT /users/1.
answered Jan 3 at 8:58


Sushrut KanetkarSushrut Kanetkar
1159
1159
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54016721%2fthe-meaning-of-stateless-in-rest-and-http%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Possible duplicate of Why is it said that "HTTP is a stateless protocol"?
– Rafael
Jan 3 at 5:24
@Rafael I'm not asking the meaning of stateless in http, but difference of stateless in rest and http
– Rhee
Jan 3 at 5:32