[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=59433#comment-59433 ] 

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

I've updated my initial analysis of which resources should support which HTTP methods to tag the "collection resources". Unfortunately we don't have a clear definition of what is and isn't a "collection resource" so I had to use some judgement in doing this. Regardless, I don't think categorizing resource by whether or not they are "collections" is going to help simplify this. I think we can all agree that "assemblies", "plans", and "services" are "collection resources", but "assemblies" and "plans" support POST, whereas "services" do not.

If we are going to simplify our description of the resource-to-HTTP-method matrix, we are going to have to find some other categorizations that coincide with the way we use HTTP to interact with the resources. Perhaps "metadata" and "non-metadata"?

https://www.oasis-open.org/apps/org/workgroup/camp/download.php/55503/resources-methods-v2.docx

> 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
>            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)