application/form+json instead of application/json

[ioseb]

I think it would be more appropriate to introduce application/form+json media type instead of using application/json media type directly.

As long as serialized JSON directly depends on the structure of HTML forms it would be nice if request processors could distinguish from submitted payload format by their Content-Type and substitute appropriate parsers instead of "guessing"...

Potential benefits

• Reduced coupling
• It will be easier to refine serialization format according to HTML forms spec
• It will be possible to apply schema validators

[darobin]

I'm not sure that I see the value in this, and the cost is effectively that it removes the value in addressing JSON services directly since most (if not all) won't recognise the new media type.

This does not reduce coupling. The purpose is to produce JSON, and that's what it does.

It won't allow us to refine serialisation any more than what we have.

It won't enable the addition of schema validators — they are already entirely possible.

Sorry, but I really don't see what this would buy us.

[ioseb]

I'm not sure that I see the value in this, and the cost is effectively that it removes the value in addressing JSON services directly since most (if not all) won't recognise the new media type.

How so? This statement implies that all existing services already recognise JSON serialized HTML forms. It is not necessary for existing services to recognize it immediately.

Submitted payload with application/json content type means anything not just serialized form, having dedicated media type like application/x-www-form-urlencoded will make it explicit for request processors how to treat transmitted content.

Additionally if i have resource /users/john-doe it can accept submitted content in:

• application/x-www-form-urlencoded
• application/hal+json
• application/vnd.collection+json

and so on, how should request processors differentiate if what application/json says that it's is just a content serialized in JSON format?

This does not reduce coupling.

Yes it does. Existing spec couples everything to application/json that means anything including simple values. Following snippets now are all valid JSON[1]:

"Hello world!"

42

true

i do not think we can say about these values that these are serialized HTML forms even though these are valid JSON serialized values.

1. http://tools.ietf.org/html/rfc7159

[cimnine]

Existing spec couples everything to application/json that means anything including simple values.

But just because an HTML form will never lead to a simple value doesn't mean it will not produce perfectly fine JSON and therefore application/json is fine as well, don't you think?

The only thing I thing that could speak for this approach is mentioned in #8:

@thoger Issue #11, which proposes the use of a new content type application/form+json instead of re-using widely used application/json, should also avoid introducing CSRF flaw in many services that use content type filtering today.

Besides that, it is never mentioned in the current draft that the outcome must conform RFC 7159 - an issue I try to address with #35.

[cameronjones]

I disagree with inventing a new mediatype for the same encoding. There is enough information in the HTTP headers to disambiguate where the request has come from. If there is the potential for CSRF then JSON encoding should use CORS to validate the origin. If sites want to do mediatype switching they can always override the HTTP response Content-Type header to whatever they choose.