- From: Yves Lafon <ylafon@w3.org>
- Date: Thu, 5 Feb 2009 09:24:51 -0500 (EST)
- To: Doug Davis <dug@us.ibm.com>
- cc: public-ws-resource-access@w3.org
On Thu, 5 Feb 2009, 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?
See the GET as a "peek head of the queue", to achieve what you want, a
POST is in order "get head of the queue".
Imagine that using an HTTP GET, your GET is executed on the server but the
connection is cut between the time the server process the queue management
and the reply is sent to the client. You probably don't want to have the
server detect that and roll-back, especially if there is a proxy
in-between, masking the connection-level error.
The client may re-issue the GET, and in your case two elements would be
removed from the queue, which is not what was wanted.
Also there is the issue of cacheability, and the fact that a proxy can
answer for the origin server without the server knowing it, making the use
of GET to change things even more dangerous.
> 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 14:25:01 UTC