Page 1 of 1

Question enthuware.ocejws.v6.2.298: wrong answer?

Posted: Mon Dec 02, 2013 8:38 pm
by socialguy
How's it true that a client's state is changed by accessing a resource?

Re: Question enthuware.ocejws.v6.2.298: wrong answer?

Posted: Tue Dec 03, 2013 6:43 am
by fjwalraven
This is what Fielding says about it (Wikipedia)
Stateless
The client–server communication is further constrained by no client context being stored on the server between requests. Each request from any client contains all of the information necessary to service the request, and session state is held in the client. Important to note is that the session state can be transferred by the server to another service such as a database to maintain a persistent state for a period of time and allow authentication. The client begins sending requests when it is ready to make the transition to a new state. While one or more requests are outstanding, the client is considered to be in transition. The representation of each application state contains links that may be used the next time the client chooses to initiate a new state-transition.

Re: Question enthuware.ocejws.v6.2.298: wrong answer?

Posted: Tue Dec 03, 2013 11:29 am
by socialguy
I'm still doubtful. Even though it says:
The client begins sending requests when it is ready to make the transition to a new state
It doesn't say that the request causes the client to change state. Though contrived, it may be argued that the client will use the data from the invocation to do something that causes a state change.

I'll admit I don't understand the following:
While one or more requests are outstanding, the client is considered to be in transition

Re: Question enthuware.ocejws.v6.2.298: wrong answer?

Posted: Wed Dec 04, 2013 3:54 pm
by fjwalraven
To get a better understanding, just read chapter 5 of Fieldings dissertation

This article of Fielding explains it nicely:
The name “Representational State Transfer” is intended to evoke an image of how a well-designed Web application behaves: a network of Web pages forms a virtual state machine, allowing a user to progress through the application by selecting a link or submitting a short data-entry form, with each action resulting in a transition to the next state of the application by transferring a representation of that state to the user.
Regards,
Frits

Re: Question enthuware.ocejws.v6.2.298: wrong answer?

Posted: Tue Apr 08, 2014 7:56 pm
by himaiMinh
I guess that is the concept of HATEOAS, hypermedia as the engine of application state.
REST architectural design has different levels.
The most basic level is using a URI to represent a resource.
The most advanced level is that a resource containing links to other resources URI's.
For example:
<FlightSchedule>
<FlightNumber>....
<DateTime> ....
<NextFlight>http://www.airlineExample.com/NextFligh ... NextFlight>
<PreviousFlight>http://www.airlineExample.com/PreviousF ... iousFlight>
</FlightSchedule>
The <NextFlight> and <PreviousFlight> are links to other resources.
The client can change the state of the resource by accessing either the next flight information or previous flight information.

Any feedback about this HATEOAS example?

Re: Question enthuware.ocejws.v6.2.298: wrong answer?

Posted: Tue Apr 08, 2014 11:12 pm
by fjwalraven
Yeah, the concept of state can confuse people. The "state" that Fielding is talking about is the state in the client, not in the server (the server should remain stateless).

Regards,
Frits

Re: Question enthuware.ocejws.v6.2.298: wrong answer?

Posted: Thu Nov 20, 2014 2:43 am
by blacksnow666

Code: Select all

A RESTful service has to use HTTP.
other than HTTP and HTTPS, what else can it use?

Re: Question enthuware.ocejws.v6.2.298: wrong answer?

Posted: Thu Nov 20, 2014 4:10 pm
by fjwalraven
This question is testing a theoretical situation. Rest (and RESTful services) are not bound to a particulair transport protocol (check Fieldings dissertation). HTTP itself doesn't fulfill all the requirements of REST. Note that REST is not about HTTP (one protocol) but about an architectural style.

In other words in theory you could have REST over another protocol than HTTP however in the practical world there is no working alternative (yet).