[
https://issues.apache.org/jira/browse/MESOS-3914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15008818#comment-15008818
]
Jan-Philip Gehrcke commented on MESOS-3914:
-------------------------------------------
{quote}
either we expect a string with key-value pairs, where values can be JSON
objects, or we request JSON directly.
{quote}
The first option is not valid:
The {{Content-Type}} header usually has a strong meaning and we should respect
this here, too. If the input is sent URL-encoded with the {{Content-Type}}
header set to {{application/x-www-form-urlencoded}}, then curly and square
brackets (for transferring a JSON object) are not allowed in the string, as of
http://tools.ietf.org/html/rfc1738 (page 2).
The input should be transferred using the {{application/json}} content type --
in which case the body should be valid JSON object in compliance with
http://www.ietf.org/rfc/rfc4627.txt.
> Make request format consistent across endpoints
> -----------------------------------------------
>
> Key: MESOS-3914
> URL: https://issues.apache.org/jira/browse/MESOS-3914
> Project: Mesos
> Issue Type: Improvement
> Components: master
> Reporter: Alexander Rukletsov
> Labels: mesosphere, tech-debt
>
> We are inconsistent with the format of requests we expect for operator
> endpoints. For example, dynamic reservations take a string
> "slaveId={{<slaveID>}}&resources={{<JSON-for-resources>}}", while maintenance
> expects a {{JSON}} object representing {{maintenance::Schedule}} protobuf
> directly.
> We should agree on the input: either we expect a string with key-value pairs,
> where values can be {{JSON}} objects, or we request {{JSON}} directly.
> Once we agree on the approach, we should document the outcome and convert all
> nonconformant endpoints via a deprecation cycle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
