You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When creating a post or uploading to the media endpoint the spec currently only requires to return a location header.
This is all fine and well if you are creating a server side app. But if you are creating a JavaScript based client at least it can be very difficult, if not impossible to read headers. All that is needed to make js clients more viable would be to return the location either in the body as plain text or a JSON object (would make more sense in case more values are required in the future).
I think this is especially relevant for media endpoints as one of the primary purposes of media endpoints is to enable rich editors which can only really be achieved on the web with JavaScript.
Having written this now however I realise it is all potentially a moot point unless micropub endpoints are set to allow cross origin requests. But still something worth considering.
The text was updated successfully, but these errors were encountered:
If the receiver creates a status page which the sender can use to check the status, the receiver must reply with an HTTP 201 Created response with a Location header pointing to the status URL. The response body may contain content.
A response body could be plaintext with the URL value of the Location header or a JSON structure as @grantcodes suggests.
So, 👍 to this one from me with the note that permitting a response body is likely more useful than requiring one as the issue title states.
I think it should be specified that if the media endpoint response body is JSON, it should be inserted as-is (e.g. into the photos array) by the client.
As I've documented on the wiki, my endpoint returns rich data for photos (multiple sources like webp+jpg or webp+png, Exif metadata, width, height, etc.) and the website displays it.
I'm not sure what's so difficult about reading headers in JS though...
This is also an issue with Shortcuts (iOS app) where it is currently impossible to read the headers of a response (the action to read headers sends a separate request).
When creating a post or uploading to the media endpoint the spec currently only requires to return a location header.
This is all fine and well if you are creating a server side app. But if you are creating a JavaScript based client at least it can be very difficult, if not impossible to read headers. All that is needed to make js clients more viable would be to return the location either in the body as plain text or a JSON object (would make more sense in case more values are required in the future).
I think this is especially relevant for media endpoints as one of the primary purposes of media endpoints is to enable rich editors which can only really be achieved on the web with JavaScript.
Having written this now however I realise it is all potentially a moot point unless micropub endpoints are set to allow cross origin requests. But still something worth considering.
The text was updated successfully, but these errors were encountered: