Re: the meaning of stateless

Will,

Correct me if I am wrong.. trying to see if I can help Mike with this but may also be incorrect in my understanding.

Mike.. let's say you have an address (application state) stored in your web application database. Now let's say your client has the user id and wants to change the phone number using the /address resource. This is say the same resource you use to create a new address by providing (as per Will's example sort of) the post office equivalent of the address form using a POST (or PUT depending on your flavor of create/update methods). In the case of updating the address, as I understand it you would not submit a PUT with the user id and just the phone number. You would first issue a GET /address with the user id to get the full "current" address. You would then send it back with a PUT and the updated phone number, so that the transaction state includes everything needed to update the address. Is this correct Will?

I ask this myself because lately I've been suing ext-js and Jersey to build MVC like web apps with Jersey acting as my server side controller via ajax requests from ext-js. In this scenario of mine, presently, I have a sort of mixed mode use of jersey/rest. I believe I am not truly using it as a pure rest framework but more like a Struts/Velocity/pick you server MVC framework flavor. I *should* (and will attempt to) use it more like a RESTful api. Presently I am still learning ext-js and just getting things to work so cutting corners.

A question I have is.. am I a bad citizen for using Jersey (or any REST framework for that matter) in this manner because of it's rather easy server side configuration and code? If I am.. I can live with it.. but I love how easy and fast it is to write jersey code. :)







>________________________________
> From: Will Hartung <[email protected]>
>To: Mike Schinkel <[email protected]> 
>Cc: Rest List <[email protected]> 
>Sent: Monday, April 22, 2013 3:37 PM
>Subject: Re: [rest-discuss] the meaning of stateless
> 
>
>
>  
>I've written a little on this before.
>
>See if reading this helps at all, as it talks not so much to state
>directly, but to sessions (which is what most folks are struggling
>with when it comes to state in REST).
>
>Feel free to hit back with questions.
>
>http://stackoverflow.com/questions/1296421/rest-complex-applications/1297275#1297275
>
>On Mon, Apr 22, 2013 at 3:33 PM, Mike Schinkel <[email protected]> wrote:
>> On Apr 22, 2013, at 6:21 PM, Will Hartung <[email protected]> wrote:
>>
>> All mentions of state within the context of REST is TRANSACTION state. A
>> TRANSACTION is a process that CHANGES (Creates, changes, or deletes) a
>> RESOURCE.
>>
>>
>> The value of a resource is NOT "STATE". The back end application as
>> represented by resources and resources have values, and REST systems then
>> offer up REPRESENTATIONS of those values.
>>
>>
>> Okay, I think I'm narrowing in on understanding, but still need a bit more
>> help.
>>
>>
>> If you want to consider the combination of Resource values managed by the
>> Application as "The State of the Application", then that's fine. But that
>> "State" is not the same "state" that we talk about when discussing the
>> "stateless" nature of REST architectures.
>>
>>
>> I think I'm getting why these are not considered stateful, because you are
>> differentiating between application state and some other kind of "bad"
>> state, right?  So if "application" state differs, what adjective do we apply
>> to the "bad" kind of state?
>>
>> Also, can you give examples of bad state and explain why it's specifically
>> bad in contrast to application state being okay?
>>
>> Many thanks in advance. This is really helping, at least it's helping me.
>>
>> -Mike
>
>-- 
>CONFIDENTIALITY NOTICE: The information contained in this electronic 
>transmission may be confidential. If you are not an intended recipient, be 
>aware that any disclosure, copying, distribution or use of the information 
>contained in this transmission is prohibited and may be unlawful. If you 
>have received this transmission in error, please notify us by email reply 
>and then erase it from your computer system.
>
> 
>
>