+1 We are saying it can happen, we just need a proposal for how clients can learn this. We require a round trip now: PUT, GET, then check.
Steve Speicher IBM Rational Software OSLC - Lifecycle integration inspired by the web -> http://open-services.net > From: Arthur Ryman <[email protected]> > To: James Conallen/Philadelphia/IBM@IBMUS, > Cc: [email protected], Adam Neal <[email protected]>, oslc- > [email protected] > Date: 09/14/2012 01:59 PM > Subject: Re: [oslc-core] Unrecognized content > Sent by: [email protected] > > Jim, > > I think we may be stretching the analogy here. > > I am OK with you proposal: "I am ok if we just state that this scenario > can happen, and that the client is responsible for determining if the > update was successful (from its view) by GETing the representation > immediately after and checking the content and comparing the ETags." > > Pls draft some text and say where it should be included so we have a > concrete proposal on the table. > > Regards, > ___________________________________________________________________________ > > Arthur Ryman > > DE, Chief Architect, Reporting & > Portfolio Strategy and Management > IBM Software, Rational > > Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) > > > > > > From: > James Conallen/Philadelphia/IBM@IBMUS > To: > Arthur Ryman/Toronto/IBM@IBMCA > Cc: > Adam Neal <[email protected]>, [email protected], > [email protected] > Date: > 09/13/2012 04:44 PM > Subject: > Re: [oslc-core] Unrecognized content > > > Arthur, > > While I am not advocating that we respond with a 4xx when the server does > not update a resource at a client's request. I point it out as an example > of how even RFC2616 requires some interpretation in context. > > What I do want to do is address this very real problem (that DM and RRC > are experiencing) that clients have when attempting to update resources > (in general). > > Using your own Java analogy, a program that essentially is > > x = -42; > out.println( x ); > > where the output is +42, because this particular type of variable only > understands positive integers, and the programmer doesn't know this. Now > he is forced to check every time he makes an assignment before proceeding > with the program > > x = -42; > if( x != -42 ) throw exception > > I think because the OSLC explicitly says that the server can ignore > unrecognized content, and there is no guaranteed way for a client to know > what content the server recognizes, the onus is on the client to be > responsible for checking the results. I think we should provide some > guidance and raise awareness of this scenario in our specs > (non-normatively), so client developers can be prepared for this > situation. > > I am ok if we just state that this scenario can happen, and that the > client is responsible for determining if the update was successful (from > its view) by GETing the representation immediately after and checking the > content and comparing the ETags. > > > Thanks, > > jim conallen > Rational Design Management (DM) Integration Architect, OSLC AM Lead > [email protected] > Rational Software, IBM Software Group > > > > > > > From: Arthur Ryman/Toronto/IBM@IBMCA > To: James Conallen/Philadelphia/IBM@IBMUS, > Cc: Adam Neal <[email protected]>, [email protected], > [email protected] > Date: 09/13/2012 04:03 PM > Subject: Re: [oslc-core] Unrecognized content > > > Jim, > > I disagree. The server ignored the content it didn't understand and did > the update, but the before and after state was the same. According to your > proposal, if I did a GET and then immediately PUT the resource, that > should also result in an error because nothing changed. That would not be > reasonable. > > Consider the following Java program: > > int x = 42; > x = 42; > > That shouldn't result in a compiler error. > > In fact, the behavior of the server is somewhat undefined if a PUT would > result in no change to the resource. The server could try to be clever and > only update the resource if some property changed. Or it could take the > request literally and replace the resource with an identical copy, but as > a side affect, the modification date of the resource might change. > > > Regards, > ___________________________________________________________________________ > > Arthur Ryman > > DE, Chief Architect, Reporting & > Portfolio Strategy and Management > IBM Software, Rational > > Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) > > > > > > > From: > James Conallen/Philadelphia/IBM@IBMUS > To: > Arthur Ryman <[email protected]> > Cc: > Adam Neal <[email protected]>, [email protected], > [email protected] > Date: > 09/07/2012 11:16 AM > Subject: > Re: [oslc-core] Unrecognized content > > > Hey Arthur, > > The spec for the PUT method says: > > If an existing resource is modified, either the 200 (OK) or 204 (No > Content) response codes SHOULD be sent to indicate successful completion > of the request. If the resource could not be created or modified with the > Request-URI, an appropriate error response SHOULD be given that reflects > the nature of the problem. > > In this scenario the server did not modify the resource, because it didn't > recognize the content. So according to RFC 2616 we should be returning an > error response. > > > Thanks, > > jim conallen > Rational Design Management (DM) Integration Architect, OSLC AM Lead > [email protected] > Rational Software, IBM Software Group > > > > > > > From: Arthur Ryman <[email protected]> > To: James Conallen/Philadelphia/IBM@IBMUS, > Cc: Adam Neal <[email protected]>, [email protected], > [email protected] > Date: 09/07/2012 10:15 AM > Subject: Re: [oslc-core] Unrecognized content > > > > -1 for the 400 response code > > Jim, I don't understand what you are asking for. The spec already makes it > > clear that the server will discard unrecognized content. The client should > > expect that. What aspect of behavior is unclear? > > Regards, > ___________________________________________________________________________ > > > Arthur Ryman > > DE, Chief Architect, Reporting & > Portfolio Strategy and Management > IBM Software, Rational > > Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) > > > > > > From: > James Conallen <[email protected]> > To: > [email protected] > Cc: > Adam Neal/Ottawa/IBM@IBMCA > Date: > 09/07/2012 09:03 AM > Subject: > [oslc-core] Unrecognized content > Sent by: > [email protected] > > > > In the current specification we have the statement: > For OSLC Defined Resources, clients SHOULD assume that an OSLC Service > will discard unknown property values. An OSLC Service MAY discard property > > values that are not part of the resource definition or Resource Shape > known by the server. > > We are running into a problem. When a client (in this case another > application server) PUTs an update to a resource that includes a 'link' to > > another OSLC resource, and the server, at the time does not recognize the > link type, the link is not accepted, but a 200 OK is returned. The server > > returns a 200 OK, because it feels like it can ignore the unrecognized > link. The client gets that 200 OK, and thinks that the link was > successfully added. > > This doesn't feel right. The only way a client can be sure that the PUT > worked as expected is to re-GET the resource and compare it to what it > expected to see (with the new link included), and maybe do a little > looking at ETags to make sure things haven't changed in between. > > I guess the server could instead return a 400 Bad Request, and include in > the response the reason for not accepting the PUT. But if the content > that was submitted really should just be ignored (i.e. is part of a future > > version of the resource), then we don't want to abort the update. > > The OSLC verbage does not provide any guidance as to what to do. It would > > be helpful if we had more detailed explanation of this statement in the > spec. > > > Thanks, > > jim conallen > Rational Design Management (DM) Integration Architect, OSLC AM Lead > [email protected] > Rational Software, IBM Software Group > _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net > > > > > > > > > _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net >
