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: [email protected] Cc: Paul McMahan/Raleigh/IBM@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 | [email protected]
