@controls: accept with schema or template

[manuel....@gmail.com]

I am a little confused about the usage of the schema porperty along with the accept property. The draft says, accept should be a string array containing the media types accepted by the server.

I assume a client would go ahead and choose the media type he prefers from this list, build the request body and send it using the chosen media type in the Content-type header.

Now what if there are multiple possible content types given in the accept property, and also a schema or a template. How is the client supposed to know, which of the media types is  described in the schema or given in the template? How does he set the Content-type header? Am I missing something here?

Regards, Manuel

[Jørn Wildt]

> Now what if there are multiple possible content types given in the accept property, and also a schema or a template. How is the client supposed to know, which of the media types is  described in the schema or given in the template?

Good question. Let me first give some background to try clarifying why it is as it is ... The "accept" property is intended *only* for use with "raw" encoding of data where Mason has nothing to say about the payload - and as such "schema" isn't supposed to be considered. Accepted formats can also be stated per file for a hypermedia control that allows file uploads (using the "json+files" encoding) - but there is no "schema" property for the files element.

So what happens if multiple formats can be accepted and there is a schema reference? What format does it apply to? I don't know - that was not considered :-)

My best answer is: It is not supported - use only "schema" or "schemaUrl" together with "json" and "json+files" encodings, not with "raw" encoding. In those two encodings your are not supposed to include an "accept" property as this is given strictly by the encoding. The documentation should probably state that "accept" is only valid with "raw" encoding - and "schema(Url)" is only valid with "json" and "json+file" encoding..

But I am open to better solutions :-)

/Jørn

--
You received this message because you are subscribed to the Google Groups "Mason media type" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mason-media-ty...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[manuel....@gmail.com]

My best answer is: It is not supported

Always a good answer ;-) 

The documentation should probably state that "accept" is only valid with "raw" encoding - and "schema(Url)" is only valid with "json" and "json+file" encoding..

Yeah, that should cover it. It should be clear that these are mutually exclusive.

In those two encodings your are not supposed to include an "accept" property as this is given strictly by the encoding.

 

Looks like the detail I missed was that encoding=json implies "application/json". I was under the assumption that this would allow any JSON based media type. 

But I am open to better solutions :-)

Can't think of any. First I was thinking, you could allow just one value for "accept" instead of an array, so that, if the encoding is set to json, you could use the schema for other json based media types too, e.g. "application/vnd.collection+json". Any other accepted type would then require an entry in the "alt" property and could include its own schema. But that would be a rather big overhead for addionallly accepted types, especially when there is no schema intended. Not sure what that would mean for "json+files" encding. I think that in the end this would do more harm than good. 

I guess, for now the best solution is to clarify  the intended usage in the spec.

Regards, Manuel

[Jørn Wildt]

> Looks like the detail I missed was that encoding=json implies "application/json". I was under the assumption that this would allow any JSON based media type.

What other JSON media types were you thinking of? Maybe I missed something here?

/Jørn

[manuel....@gmail.com]

Collection+JSON for example, like I mentioned above. Or something proprietary for the application. Basicly anything ending with "+json".

Regards, Manuel