[oslc-core] Requests for unknown or unsupported properties

[Paul McMahan]

Sam,

In the example you mentioned the properties are optional.   I could see an
argument for responding with 400 Bad Request when the properties are
unknown.   But responding with 400 Bad Request when the properties are
optional seems counter-intuitive because it implies that the client is at
least partially responsible for the failure.

For example, if the client sent a syntactically incorrect query string then
I would expect the server to return 400 Bad Request.  But in the example
you mentioned the client is using properties that are explicitly defined in
the CM specification.   For this case I could see the server possibly
returning HTTP 5XX response code to indicate that the request is valid but
the server can't support it.   However, I don't see any perfect match for
this case in the standardized HTTP response codes [1].    And expecting the
client to always check for 5XX to detect this special case when they are
actually sending a valid request seems too burdensome anyway.  So IMO if
the client includes an optional property in oslc.select, oslc.where, or
oslc.properties then it should expect a HTTP 200 response but be prepared
to deal with results that don't contain that property.

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html


Best wishes,
Paul McMahan
IBM Rational



From:	Samuel Padgett/Durham/IBM
To:	oslc-core at open-services.net
Cc:	Paul McMahan/Raleigh/IBM at IBMUS
Date:	03/26/2012 09:04 AM
Subject:	Requests for unknown or unsupported properties


I couldn't find clear guidance on how providers should respond to requests
for unknown properties, for instance in an oslc.properties or oslc.select
parameter. This might be a request for a non-standard property that a
provider doesn't recognize (e.g., http://example.com/ns#customProperty) or
a standard, but optional property not supported by the provider.

An example from the CM domain is state predicates, which are optional
properties on a ChangeRequest resource [1]. How should a provider respond
to these queries if it doesn't support oslc_cm:approved? (I've left the
query parameters unescaped and omitted oslc.prefix for readability.)

http://example.com/bugs/34?oslc.properties=oslc_cm:approved
http://example.com/bugs?oslc.select=oslc_cm:approved
http://example.com/bugs?oslc.where=oslc_cm:approved=true

Either responding with a 400 Bad Request or simply leaving unknown
properties out of the response seem like reasonable choices. I propose we
advise providers to simply leave the unknown properties out of the
response. This way consumers can request optional properties without fear
of running into errors. In the case of the oslc.where query above,
providers might simply return no results.

I suggest we update OSLC Core Spec Selective Property Values [2] and the
query specification [3] with guidance.

[1]
http://open-services.net/bin/view/Main/CmSpecificationV2?sortcol=table;up=#Resource_ChangeRequest
[2]
http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;table=up;up=#Selective_Property_Values
[3] http://open-services.net/bin/view/Main/OSLCCoreSpecQuery
--
Best Regards,
Samuel Padgett | IBM Rational | spadgett at us.ibm.com