Re: http get safeness

 > Do I really need to model this as a GET followed by a DELETE just to 
avoid the "no side-effects" rule?

IMHO, you need to model this as a GET followed by a operation that 
changes the queue.
As you said, GET should not have side effects.
All the best, Ashok


Doug Davis wrote:
>
> Yves,
>   this is a bit off topic but its something I've always wondered about.  
> People are always talking about this safeness/idempotency of HTTP GET,
> but how strong does this rule need to be?  For example, let's say I 
> have a
> URI that refers to the head of a queue - not the entire queue, just 
> the head.
> And doing an HTTP GET pulls back the head item in the queue - and removes
> it from the queue as well.  Is this a violation of best practices of 
> the web because
> HTTP GET has side-effects?  Do I really need to model this as a GET 
> followed by
> a DELETE just to avoid the "no side-effects" rule?
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
>
>
> *Yves Lafon <ylafon@w3.org>*
>
> 02/05/2009 04:47 AM
>
> 	
> To
> 	Doug Davis/Raleigh/IBM@IBMUS
> cc
> 	public-ws-resource-access@w3.org
> Subject
> 	RE: issue 6398: updated proposal
>
>
>
> 	
>
>
>
>
>
> On Wed, 4 Feb 2009, Doug Davis wrote:
>
> > To follow-up on the conf call yesterday....
> >
> > Geoff mentioned the Team Comments on WS-Transfer [1] as an implicit
> > endorsement of the supposed alignment between HTTP and WS-Transfer.
> > However, I think this is not the case:
> > - the team comments do not actually say that the "parallel" between HTTP
> > and WS-Transfer is a good thing it just points out that both have 
> similar
> > verbs/operations.
> > - in fact, after this similarity is pointed out the comments go on 
> to say
> > how misaligned WS-Transfer is with the Web due to the use of EPRs 
> instead
> > of URIs.  It says things like WS-Transfer resources could be
> > "...unsuitable for referencing and use in other Web technologies".
>
> There is also another point, the lack of 'safeness' and 'idempotency'
> properties in the definition of those 'verbs'.
> In HTTP, it is safe to reissue a GET when something happens at the
> conncetion level, for example.
>
> The analogy in WS-T would be to say that GET is safe, and if you receive
> no response, it is safe to reissue the request again (think of SOAP over
> email, or over UDP where timeouts may be involved).
>
> A DELETE, if not safe is idempotent, meaning that two DELETE will still
> result in the resource being deleted.
>
> I am lodging a new issue about that right now :)
>
> > - add to this Tim's comments [2], as Bob pointed out on the call, that
> > there is a concern over WS-Transfer's lack of alignment with HTTP around
> > such things as its use (or lack of use) of HTTP GET.  Its worth noting
> > that Tim reiterates the concern about the misalignment of 
> WS-Transfer with
> > the Web itself because of its use of EPRs.
>
> > - also, no where in the team comments do they make any reference to the
> > notion that because the Body is 'unwrapped' its more aligned with 
> HTTP. It
> > doesn't even touch on this subject at all.  And, as I pointed out on the
> > call, this would be a mistake for them to even head down this path 
> because
> > there are lots of cases where the HTTP Body is wrapped (like
> > mime-encoding) and those are clearly not misaligned with HTTP.
> >
> > I do agree with Geoff that the alignment of WS-Transfer with HTTP, 
> and the
> > Web itself, should be more closely examined - especially given the
> > Team/Tag/Tim comments - but this is a separate issue that has nothing to
> > do with whether the Transfer operations include a wrapper in the Body or
> > not.
> >
> > [1]  http://www.w3.org/Submission/2006/04/Comment
> > [2] http://lists.w3.org/Archives/Public/www-tag/2006Oct/0061.html
> >
> > thanks
> > -Doug
> > ______________________________________________________
> > STSM |  Standards Architect  |  IBM Software Group
> > (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
> >
> >
> >
> > Geoff Bullen <Geoff.Bullen@microsoft.com>
> > Sent by: public-ws-resource-access-request@w3.org
> > 02/03/2009 12:35 PM
> >
> > To
> > Doug Davis/Raleigh/IBM@IBMUS
> > cc
> > "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
> > Subject
> > RE: issue 6398: updated proposal
> >
> >
> >
> >
> >
> >
> > Hi Doug,
> > Having re-read our previous email a couple of times, it is still kind of
> > unclear exactly what you think we are in agreement on here. J  While 
> it is
> > hopeful we will find common ground at some point, we are not there yet.
> >
> > Regarding Transfer Create Operation ?
> >
> > T.Create and RT.Create currently have different cardinalities and one of
> > them therefore must change in order for them to remain ?in sync?.
> >
> > The current version of T.Create() states that the first child 
> element MUST
> > NOT be omitted. But the draft proposal allows senders to emit empty 
> Create
> > requests. This means, current Transfer Resource Factories cannot process
> > the proposed Create request messages without changing the underlying
> > processing logic.
> >
> > Cheers,
> > Geoff
> >
> >
> >
> > From: Doug Davis [mailto:dug@us.ibm.com]
> > Sent: Monday, February 02, 2009 5:27 PM
> > To: Geoff Bullen
> > Cc: public-ws-resource-access@w3.org
> > Subject: RE: issue 6398: updated proposal
> >
> >
> > Geoff,
> >  thanks for the comments.  I'm glad that we're in agreement that 
> there is
> > no functional difference between what the current version of 
> Transfer and
> > my proposal because I tried to ensure that it was just a syntax 
> change. As
> > to the change of cardinality of Create, I was very clear as to why I
> > changed it - please reread my proposal.  Also, it does not break 
> backwards
> > compatibility - aside from the addition of a wrapper, existing impls 
> will
> > still be sending valid WS-T messages.
> >
> > thanks
> > -Doug
> > ______________________________________________________
> > STSM |  Standards Architect  |  IBM Software Group
> > (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
> >
> >
> > Geoff Bullen <Geoff.Bullen@microsoft.com>
> > 02/02/2009 07:32 PM
> >
> >
> > To
> > Doug Davis/Raleigh/IBM@IBMUS
> > cc
> > "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
> > Subject
> > RE: issue 6398: updated proposal
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Doug,
> > We have been looking more closely at the wrapper issue (Issue 6398) and
> > your current proposal and there are a number of concerns that we have.
> >
> > Summary
> > We believe that the proposed changes will affect the current 
> alignment of
> > Transfer with HTTP, and that it breaks the current implementation of
> > Transfer by changing the cardinality of  message formats.  More specific
> > details can be seen below:
> >
> > 1) Wrappers and the Alignment of Transfer with HTTP
> > We believe that the proposed wrapper changes disrupt the current 
> alignment
> > between Transfer and HTTP.  Since the TAG articulated in Nov, 2008 that
> > they were interested in a closer alignment between Transfer and HTTP, it
> > is unclear to us if this is the right direction for the WG to be 
> heading.
> >
> > There are a set of principles that guide us as we move through this 
> issue:
> > a) Transfer continues to have alignment with HTTP as much as possible.
> > b) Transfer is built on WS-A and honors the WS-A action based dispatch
> > model.
> > c) Transfer should be aligned with Basic Profile as much as possible.
> >
> > With regards to goal a) above, the HTTP message body carries the content
> > (or message body) and not the verb (action).  In the same way, the
> > Transfer SOAP body carries the content and not the action. We believe
> > using specific wrapper element names, such as <get> and <getresponse>,
> > implies there is semantic meaning in those names, which affects the
> > separation described above and thus disrupts the existing alignment
> > between Transfer and HTTP.  Any semantic meaning also goes against goal
> > b).
> >
> > Also with regards to goal a), the WG has not yet received any technical
> > comments from the TAG nor has the TAG articulated its wishes clearly to
> > us.  Shouldn't we engage the TAG ASAP?
> >
> >
> > 2) Wrappers, Cardinality and the Create verb
> > While you expressed a desire to treat cardinality as separate from the
> > wrapper issue, your proposal does in fact change the cardinality of the
> > Transfer messages, Delete and Create.  While changing the cardinality of
> > T.delete does not break backwards compatibility, changing the 
> cardinality
> > of T.create certainly does.  It is unclear to us why your proposal has
> > chosen to break backwards compatibility with T implementations.  It 
> is our
> > understanding that there are many current interoperable 
> implementations of
> > the T spec, so would not it be more prudent to align more closely 
> with the
> > current version of T?
> >
> > --Geoff
> >
> >
> > From: public-ws-resource-access-request@w3.org
> > [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug 
> Davis
> > Sent: Sunday, January 18, 2009 10:34 AM
> > To: public-ws-resource-access@w3.org
> > Subject: RE: issue 6398: updated proposal
> >
> >
> > Hey Geoff,
> > thanks for the heads up on the cardinality - I'll double check those -
> > but what's correct depends on whether you're looking at the schema 
> or the
> > text of the spec.  For example, GetResponse, per the pseudo schema 
> should
> > be as you noted (+), but per the schema it should be a singleton. 
>  Either
> > way - this is our chance to make sure things are aligned. As for the MEX
> > change, despite some possible ribbing from Jeff :-), I like 
> consistency -
> > so if you open an issue I wouldn't object.
> >
> > All,
> > below is a modified version of the proposal, showing the pseudo schema
> > changes to T and RT (some of the cardinalities will vary slightly from
> > previous proposal and from the specs in an effort to ensure things are
> > consistent and allow for RT to do its job) - I tried to make a note of
> > each one as I detected it (hopefully the following shows up ok for
> > everyone - if not let me know and I'll put it into a separate file):
> >
> > T-GetRequest:                 RT-GetRequest:
> > <wst:Get ... >                <wst:Get Dialect="xs:anyURI" ...>
> > xs:any *                       <wsrt:Expression ...> xs:any
> > </wsrt:Expression> *
> > </wst:Get>                    </wst:Get>
> > Note: to allow for more than one Expression, I had to change the 'xs:any
> > ?' to a "xs:any *" on the xs:any of the T.Get(), and for full
> > extensibility (an attribute on Get could make the need for children
> > unnecessary).
> >
> > T-GetResponse:                RT-GetResponse:
> > <wst:GetResponse ...>         <wst:GetResponse ...>
> > xs:any +                         <wsrt:Result...>xs:any</wsrt:Result> +
> > </wst:GetResponse>            </wst:GetResponce>
> > Note: We should consider changing the "xs:any +" to "xs:any *" since the
> > resource representation could technically be empty and we should 
> allow for
> > that (<wsrt:Result>+ too), and for full extensibility (an attribute on
> > GetResponse could make the need for children unnecessary).
> >
> > T-PutRequest:                 RT-PutRequest:
> > <wst:Put ...>                 <wst:Put Dialect="xs:anyURI" ...>
> > xs:any +                       <wsrt:Fragment ...> +
> > </wst:Put>                    <wst:Put>
> > Note: We should change "xs:any +" to "xs:any *" to allow for an empty
> > represenation to be 'put', and for full extensibility (an attribute 
> on Put
> > could make the need for children unnecessary).
> >
> > T-PutResponse:                RT-PutResponse:
> > <wst:PutResponse ...>         <wst:PutResponse ...>
> > xs:any ?                       xs:any ?
> > </wst:PutResponse>            </wst:PutResponse>
> > Note: We should change the "xs:any ?" to "xs:any *" to allow for full
> > extensbility.
> >
> > T-DeleteRequest:              RT-DeleteRequest:
> > <wst:Delete ...>              <wst:Delete ...>
> > xs:any *                      xs:any *
> > </wst:Delete>                 </wst:Delete>
> > Note: I added the "xs:any *" extensibility point in here.
> >
> > T-DeleteResponse:             RT-DeleteResponse:
> > <wst:DeleteResponse ...>      <wst:DeleteResponse>
> > xs:any ?                       xs:any ?
> > </wst:DeleteResponse>         </wst:DeleteResponse>
> > Note: We should change the "xs:any ?" to "xs:any *" to allow for full
> > extensbility.
> >
> > T-CreateRequest:              RT-CreateRequest:
> > <wst:Create ...>              <wst:Create Dialect="xs:anyURI" ...>
> > xs:any *                       <wsmex:Metadata ...> ?
> >                               <wsrt:Fragment ...> *
> > </wst:CreateRequest>          </wst:CreateRequest>
> > Note: I changed the "xs:any +" to "xs:any *" for three reasons: 1) it
> > seems like it should be possible to allow the entire resource to have
> > default values, 2) per the RT spec the mex and fragment elements are
> > optional, 3) to allow for full extensibility (an attribute on the Create
> > could make up for the absence of child elements).
> >
> > T-CreateResponse:             RT-CreateResponse:
> > <wst:CreateResponse ...>      <wst:CreateResponse ...>
> > <wst:ResourceCreated>         <wst:ResourceCreated>
> > xs:any ?                      xs:any ?
> > </wst:CreateResponse>         </wst:CreateResponse>
> > Note: We should change the "xs:any ?" to "xs:any *" to allow for full
> > extensbility.
> >
> > We should discuss the "xs:any ?" -> "xs:any *" notes I made - if there
> > isn't any objection we can include it as part of this.
> >
> > thanks
> > -Doug
> > ______________________________________________________
> > STSM  |  Web Services Architect  |  IBM Software Group
> > (919) 254-6905  |  IBM T/L 444-6905  |  dug@us.ibm.com
> >
> > Geoff Bullen <Geoff.Bullen@microsoft.com>
> > Sent by: public-ws-resource-access-request@w3.org
> > 01/16/2009 12:09 PM
> > To
> > Doug Davis/Raleigh/IBM@IBMUS
> > cc
> > "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
> > Subject
> > RE: issue 6398: updated proposal
> >
> >
> >
> >
> >
> >
> >
> > Doug,
> > A couple of things:
> > 1)      I believe the "xs:any" defined in GetResponse, PutRequest,
> > CreateRequest should actually be "xs:any +" defining  one or more.
> > 2)      I am wondering if, for the sake of consistency and 
> extensibility,
> > we should also be looking at the GetMetadata Request and Response 
> messages
> > in MEX and adding a similar outer wrappers and extensibility concepts?
> > Thoughts?
> > --Geoff
> >
> > From: public-ws-resource-access-request@w3.org
> > [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug 
> Davis
> > Sent: Thursday, January 15, 2009 6:36 AM
> > To: public-ws-resource-access@w3.org
> > Subject: issue 6398: updated proposal
> >
> >
> > per my AI from yesterday, the updated pseudo schema for the wrapped
> > WS-Transfer operations would be:
> >
> > GetRequest:
> > <wst:Get ... >
> > xs:any ?
> > </wst:Get>
> >
> > GetResponse:
> > <wst:GetResponse ...>
> > xs:any
> > </wst:GetResponse>
> >
> > PutRequest:
> > <wst:PutRequest ...>
> > xs:any
> > </wst:PutRequest>
> >
> > PutResponse:
> > <wst:PutResponse ...>
> > xs:any ?
> > </wst:PutResponse>
> >
> > DeleteResponse:
> > <wst:DeleteResponse ...>
> > xs:any ?
> > </wst:DeleteResponse>
> >
> > CreateRequest:
> > <wst:CreateRequest ...>
> > xs:any
> > </wst:CreateRequest>
> >
> > CreateResponse:
> > <wst:CreateResponse ...>
> > <wxf:ResourceCreated>endpoint-reference</wxf:ResourceCreated>
> > xs:any ?
> > </wst:CreateResponse>
> >
> > In looking at how this impacts RT... it shouldn't. RT overrides T's Body
> > (in some cases already using a wrapper similar to the above) so that can
> > continue as is. The only thing missing from the previous proposal 
> was the
> > extensibilty points on the wrapper elements so that attributes could be
> > added - but that was a typo :-) .  Existing RT can continue to override
> > the the above messages with a well defined element - this, along 
> with the
> > RT header allows the receiver to know this isn't a normal/vanilla 
> Transfer
> > operation.
> >
> > There is no impact on MEX.  I couldn't find any reference to the 
> transfer
> > operations that needed to be changed - no samples using it either.
> >
> > thanks
> > -Doug
> > ______________________________________________________
> > STSM  |  Web Services Architect  |  IBM Software Group
> > (919) 254-6905  |  IBM T/L 444-6905  |  dug@us.ibm.com
> >
>
> -- 
> Baroula que barouleras, au tiéu toujou t'entourneras.
>
>         ~~Yves
>
>

Received on Thursday, 5 February 2009 16:25:21 UTC