OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

Gilbert Pilz commented on CAMP-180:

The most important part of this issue is not the structure of the spec document, but which HTTP methods are supported by which CAMP resources. I've uploaded a list of CAMP resources and the HTTP methods I think it makes sense for them to support here: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/55352/resources-methods-v1.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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]