[occi-wg] HTTP rendering doc out of public comment
tmetsch at platform.com
Wed Mar 30 08:16:33 CDT 2011
>> I'm not sure about the following:
>> * Only show mutable attributes in the query interface
> This I feel to be very important indeed. Without this change an OCCI
> client _cannot_ use the query interface to determine the requirements for
> successful POST request!
> To understand the issue you must think from a OCCI client perspective. The
> "attributes" listed for each Category is used by a client to determine
> which attributes to submit when doing a POST of a new resource instance. A
> well-behaved OCCI service impl will return a Bad Request error if a client
> tries to change an immutable attribute. Therefore the "attributes" list
> must only include mutable attributes.
> - Client queries /-/ and finds the "compute" resource.
> - The "attributes" parameter includes occi.compute.state,
> occi.compute.speed, etc
> - Client presents the attributes found for "compute" to (in this example)
> an end-user
> - The end-user sets desired values for all attributes and asks the OCCI
> client to create a new compute resource instance.
> - The dutiful OCCI client then sends occi.compute.state in the POST
> request to the OCCI service implementation.
> - Since occi.compute.state is immutable the well-behaved OCCI service will
> return a Bad Request.
> - The spec does not define how to interpret the cause of a particular Bad
> Request error so now the OCCI client doesn't know why the POST request
> The best solution would be to somehow include the mutability of all
> attributes in the query interface. The quick and dirty solution is to only
> include mutable attributes in the query interface.
well indeed quick and dirty :-) I see you're point and would suggest we express the mutability in the query interface but for all attributes...
More information about the occi-wg