Ability to choose content type; upload files?

[nylen]

It looks like they are sent as GET parameters instead:

@southp found that this is causing "HTTP 414 - Request - URI Too Long" when posting lots of content to a comment, for example.

Ideally we could also choose the request format between a few different options:

• application/x-www-form-urlencoded
• multipart/form-data (allows uploading files for testing the "upload media" endpoints)
• application/json
• GET parameters (is this useful? maybe not)

[youknowriad]

Yes, that would be better, but since the discovery doesn't give us informations on how we should send each args, they are sent as GET parameters.

It looks like the API accepts the parameters no matter how you send them, so we could rely on the method and use GET parameters only for GET endpoints.

Also about the different options on how to serialize the parameters on the body, I think to simplify we should force a format (maybe json) and if we detect files on the parameters we switch to multipart?

[youknowriad]

Maybe I'm missing something but I think there is no information about the file arguments on the discovery results? I tried to look at POST /media but found nothing about the files there. Is this a concern or maybe I am looking in the wrong place?

[nylen]

It looks like the API accepts the parameters no matter how you send them, so we could rely on the method and use GET parameters only for GET endpoints.

Yes, this is true, and that seems fine to me.

I think to simplify we should force a format (maybe json)

No strong preference here, it just seems like kind of a nice enhancement to be able to pick the request format. The only reason I can think of this being "useful" rather than just "cool" is that it would let you look for bugs in handling of different data types: id=3 (string) vs {"id":3} (number).

Maybe I'm missing something but I think there is no information about the file arguments on the discovery results?

Yes, this is true. In v1 there are a couple of endpoints that accept files. In v2, POST /wp/v2/media is the only one. It doesn't fit perfectly with the way the schema/args system is currently set up though:

• The file can also be sent as the raw, binary POST content with the appropriate Content-Type.
• There is no type: "file" support in schema/args currently.

Is this a concern

Want to create a core Trac ticket to add { file: { type: 'file', ... } } to the endpoint args? I think this is a good idea if we can manage it. It's not currently documented at http://v2.wp-api.org/reference/media/ either which made it difficult for me to figure out how to use this endpoint.

Otherwise, we can add a special case in the console for the endpoints that accept media files.

I think I have started to discuss too many things on this issue 😄 all of this except for #29 is definitely enhancements and not required before we ship this new version of the console.