[oslc-core] Unrecognized content
Steve K Speicher
sspeiche at us.ibm.com
Tue Sep 18 08:50:48 EDT 2012
+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 <ryman at ca.ibm.com>
> To: James Conallen/Philadelphia/IBM at IBMUS,
> Cc: Oslc-Core at open-services.net, Adam Neal <Adam_Neal at ca.ibm.com>, oslc-
> core-bounces at open-services.net
> Date: 09/14/2012 01:59 PM
> Subject: Re: [oslc-core] Unrecognized content
> Sent by: oslc-core-bounces at open-services.net
>
> 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 at IBMUS
> To:
> Arthur Ryman/Toronto/IBM at IBMCA
> Cc:
> Adam Neal <Adam_Neal at ca.ibm.com>, Oslc-Core at open-services.net,
> oslc-core-bounces at open-services.net
> 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
> jconallen at us.ibm.com
> Rational Software, IBM Software Group
>
>
>
>
>
>
> From: Arthur Ryman/Toronto/IBM at IBMCA
> To: James Conallen/Philadelphia/IBM at IBMUS,
> Cc: Adam Neal <Adam_Neal at ca.ibm.com>, Oslc-Core at open-services.net,
> oslc-core-bounces at open-services.net
> 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 at IBMUS
> To:
> Arthur Ryman <ryman at ca.ibm.com>
> Cc:
> Adam Neal <Adam_Neal at ca.ibm.com>, Oslc-Core at open-services.net,
> oslc-core-bounces at open-services.net
> 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
> jconallen at us.ibm.com
> Rational Software, IBM Software Group
>
>
>
>
>
>
> From: Arthur Ryman <ryman at ca.ibm.com>
> To: James Conallen/Philadelphia/IBM at IBMUS,
> Cc: Adam Neal <Adam_Neal at ca.ibm.com>, Oslc-Core at open-services.net,
> oslc-core-bounces at open-services.net
> 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 <jconallen at us.ibm.com>
> To:
> Oslc-Core at open-services.net
> Cc:
> Adam Neal/Ottawa/IBM at IBMCA
> Date:
> 09/07/2012 09:03 AM
> Subject:
> [oslc-core] Unrecognized content
> Sent by:
> oslc-core-bounces at open-services.net
>
>
>
> 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
> jconallen at us.ibm.com
> Rational Software, IBM Software Group
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>
>
>
>
>
>
>
>
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>
More information about the Oslc-Core
mailing list