Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider requiring a response body for returned locations #108

Open
grantcodes opened this issue May 22, 2018 · 3 comments
Open

Consider requiring a response body for returned locations #108

grantcodes opened this issue May 22, 2018 · 3 comments

Comments

@grantcodes
Copy link

grantcodes commented May 22, 2018

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.

@jgarber623
Copy link
Contributor

jgarber623 commented Jun 30, 2018

This suggestion would be consistent with Section 3.2 Receiving Webmentions in the Webmention spec:

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.

@valpackett
Copy link

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...

const resp = await fetch(endpoint, {...})
const location = resp.headers.get('Location')

@RosemaryOrchard
Copy link

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants