[OASIS Issue Tracker] (CAMP-180) PUT and PATCH don't make sense for all resources

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/CAMP-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59665#comment-59665 ] 

Gilbert Pilz commented on CAMP-180:
-----------------------------------

This issue is related to CAMP-192 and probably cannot be resolved until we resolve that issue. A cleaner separation of resources into "plain resources" and "container resources" would make it easier to apply some generic rules with regards to HTTP method support. For example would could state that, in general, all container resources support GET and POST, but not PUT and DELETE. What complicates this is the distinction between metadata and non-metadata resource and collections. For example, it is difficult to imagine why a CAMP implementation would want/need to support POST on the top-level collection of type_definition resources; users are not generally allowed to add to the metadata.

One thing that might help clean things up is if we abandoned the idea of user-modifiable "description" and "tags" attributes on collection resources. If these didn't exist it would be pretty easy to make the case that collection resources did not need to support PUT or PATCH. Does it really make sense to tag, for example, the entire to collection of assemblies that are visible to the user - which is what tagging the "assemblies resource" really amounts to?

> PUT and PATCH don't make sense for all resources
> ------------------------------------------------
>
>                 Key: CAMP-180
>                 URL: https://issues.oasis-open.org/browse/CAMP-180
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>          Components: Spec
>    Affects Versions: 1.2
>            Reporter: Gilbert Pilz
>            Assignee: Gilbert Pilz
>            Priority: Minor
>
> Section 5.5, "HTTP Method Support", of CAMP 1.1 states the following:
> "As described in Section 6.1, “Transfer Protocol”, Consumers use HTTP [RFC2616] to interact with CAMP defined resources. To foster interoperability it is necessary to define the HTTP methods supported by
> each resource. Note that a requirement on the Provider to support a particular HTTP method on a resource does not ensure that all requests to that resource using that method will succeed; it simply guarantees that the Provider will not fail such requests with a 405 (Method Not Allowed) error.
> Providers SHALL support the HTTP GET, PUT, and PATCH methods on all of the resources defined in this section. [RE-53]"
> However, there are a number of CAMP-defined resources for which this simply does not make sense; there are resources which are essentially "read-only" in nature. For example, one of the "type_definition" resources. Even if you accept the general notion that a client may want to tag various resources for any number of reasons, it is difficult to imagine why someone would attempt to add a tag to a type_definition resource. These resources exist solely to allow the provider to advertise the resource types supported by the platform.
> If we accept the idea that some CAMP resources are "read-only", what should a provider do if a client attempts a PUT or a PATCH method on these resources? 405 is the most honest response to such a request.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)