Uploaded image for project: 'OASIS Cloud Application Management for Platforms (CAMP) TC'
  1. OASIS Cloud Application Management for Platforms (CAMP) TC
  2. CAMP-13

Media Type "type" argument not compatible with Python request parsers

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Spec
    • Labels:
      None
    • Proposal:
      Hide

      Each resource SHALL have a type attribute that Identifies the name of the type of the resource. Such resources SHALL be set with a Content-Type: application/json header in the HTTP response, and the body SHALL contain the type attribute.

      Example:

      Content-Type: application/json

      {
      "type" : "assembly",
      "uri" : "http://camp.example.org/assembly/1",
      "name" : "/example",
      "created" : "2012-11-14T00:00Z",
      ...
      }

      The type list will be defined elsewhere, in accordance with https://tools.oasis-open.org/issues/browse/CAMP-29

      Show
      Each resource SHALL have a type attribute that Identifies the name of the type of the resource. Such resources SHALL be set with a Content-Type: application/json header in the HTTP response, and the body SHALL contain the type attribute. Example: Content-Type: application/json { "type" : "assembly", "uri" : "http://camp.example.org/assembly/1", "name" : "/example", "created" : "2012-11-14T00:00Z", ... } The type list will be defined elsewhere, in accordance with https://tools.oasis-open.org/issues/browse/CAMP-29

      Description

      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

        Attachments

          Activity

            People

            • Assignee:
              adrian.otto Adrian Otto (Inactive)
              Reporter:
              akarmark Anish Karmarkar (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: