> the idea is that > an attempt to actually modify a state predicate value SHOULD result > in a 409 error, but just having the value in the PUT request MUST > NOT cause if an error if it's unchanged. This is true for both full > and partial update.
Now I understand, so +1 on this approach as well. I would be explicit about the fact that a value was provided for the read-only property that was different from the one in the resource. This should be the behavior for all read-only properties, and I still think should be captured in the CORE spec. This way clients can expect consistent behavior for any read-only properties. ___________________________________________________________________________ Samit Mehta Lead Architect, ISV Enablement & Ready for IBM Rational software validation IBM Rational Software - Business Development (512) 323-9350 - Work mailto:[email protected] Samuel Padgett/Durham/IBM wrote on 03/26/2012 02:00:38 PM: > From: Samuel Padgett/Durham/IBM > To: Samit Mehta/San Francisco/IBM@IBMUS > Cc: [email protected], Paul McMahan/Raleigh/IBM@IBMUS > Date: 03/26/2012 02:00 PM > Subject: Re: [oslc-cm] State Predicates > > Hi, Samit. Thanks. My comments below. > > > > An attempt to update read-only > > > predicates SHOULD be answered with a 409 Conflict HTTP status code. Their > > > presence in a resource representation used for an update via PUT MUST NOT > > > prevent the resource from being updated. > > Would the first sentence above be applicable to update via PARTIAL > > PUT only? If yes, then let's add that to Sam's suggested update > to the spec. > > > > Similarly, is the second sentence above be applicable to update via > > PUT where the entire resource is provided in the request? What is > > the general recommendation (i.e. what's spec'd in the CORE spec) for > > a PUT with regards to read-only properties? I couldn't find a clear > > indication in CORE spec on how a provider should handle read-only > > properties being specified in the request document for an update of > > resources via PUT. It may be a good idea to be more clear about > > this in the CORE spec, and possibly repeat it in the OSLC CM spec > > for predicates to be more clear for someone reading the CM spec only. > > Maybe these statements could also be clearer, but the idea is that > an attempt to actually modify a state predicate value SHOULD result > in a 409 error, but just having the value in the PUT request MUST > NOT cause if an error if it's unchanged. This is true for both full > and partial update. > > > > There is a second issue... > > > It's also not clear how providers should respond to requests for > > > state predicates when they're not supported. > > > > +1 on the specification needing to be clear on how consumers can > > know whether a provider supports a specific state predicate. I > > don't think it is relevant for the consumer to find out whether the > > provider has support for state predicates in general, just a specific one. > > > > How are the current providers (e.g. ClearQuest, RTC, and Change) > > handling this currently? > > I believe ClearQuest returns a 400 Bad Request if you ask for a > property that is not defined. I'm not sure about RTC and Change. The > JIRA provider just leaves it out of the response. > > My preference is to simply leave it out of the response. > > - Sam
