Revision Content Types.

[mjallday]

Spurred mainly by #478.

I like @mahmoudimus' suggestion of Content-Type: text/www-url-encoded; revision=1.0, it mirrors the Accept header.

This should help with migration scenarios where you do not control the payload. e.g. if you are using a 3rd party to perform some operations on your behalf.

If we implement #478 this will also help balanced/balanced-dashboard#898 since we could send an array of credits and perform an atomic operation rather than sending them to the API one-by-one.

[steveklabnik]

Sorry, "revision" content types?

[mjallday]

Is it possible to use the content-type to specify which revision of the API should process your payload?

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

The Accept request-header field can be used to specify certain media types which are acceptable for the response.

The Content-Type entity-header field indicates the media type of the entity-body sent to the recipient

If I say

• Accept: application/vnd.balanced+api;version=1.1
• Content-Type: text/www-url-encoded; version=1.0

what I mean is "please take this revision 1.0 payload that is url-encoded and parse that and then return me a 1.1 json response".

Am I making sense here? I want the ability to unpick the payload that I send from the response I get back.

[mahmoudimus]

@mjallday that's the correct way to negotiate content with the API. To describe the content coming in, you should describe the entity's MIME type to see if the API supports it.

[mahmoudimus]

478 is relevant here.