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] Commented: (CAMP-13) Media Type "type" argument not compatible with Python request parsers


    [ http://tools.oasis-open.org/issues/browse/CAMP-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=31733#action_31733 ] 

Adrian Otto commented on CAMP-13:
---------------------------------

Proposal:

Each resource SHALL have a type resource that Identifies the name of the type of the resource, and a rel link to a specification resource that defines the type. The platform will provide the following standard types, and resources describing each:

component
requirement
capability
template
error
assembly

The resource type identifier SHALL be part of the top level JSON of any HTTP response that has a body. Example:

{ 
    "type" : "component", 
    "origin" : { "name" : "platform", "rel" : "http://..."; }
     ...
}

> Media Type "type" argument not compatible with Python request parsers
> ---------------------------------------------------------------------
>
>                 Key: CAMP-13
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-13
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Improvement
>          Components: Spec
>            Reporter: Anish Karmarkar
>            Assignee: Adrian Otto
>
> In creating the spec there was a compromise made for how the spec should handle Media Types:
> > We register exactly one media type for all resources: application/name+format
> > The specific resource type is declared via a "type" parameter:
> > application/name+format;type=type
> > We allow different formats to be delivered, with JSON being the default (and hence required)
> > format: application/name+json;type=type
> > In case XML is delivered, it is just another format. I.e. we don't define any schemata or aid in
> > validating Format discovery should happen through a GET on the /api/formats URL but
> > implementations are free to not provide this in which case clients need to fall back to discovery
> > by trial (via the "Accept" header)
> > If alternative formats are supported, they need to be supported uniformly for all resources
> It has come to my attention that the Openstack group tried to use this technique, and could not make it work in Python. The Python request parsing libraries (they tried all the available choices apparently) did not recognize the parameter, and stripped it. They were able to handle the q= parameter, but not type=.
> Considering the popularity of Python in web service API's it would be a mistake to proceed with our current strategy of using the type= parameter unless the Python request parsing libraries are first enhanced to be able to deal with it properly, and not strip it from the request.
> It may also affect other languages/systems in a similar way.
> This issue was raised by Adrian Otto and was drupal issue 1075

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


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