Response from Media Endpoint

[dshanske]

The Micropub spec doesn't define a particular response body when uploading to the media endpoint. It only defines that the response include the created URL in the Location header. However, some tools are easier to work with if they can use the response body instead of having to parse the HTTP headers.

This should also be the same response format used when querying the endpoint to find the last thing uploaded or other proposed queries

The minimum response body is a url property. There are suggestions of other properties it might return, including parsed metadata, alternative file version, etc.

• Width/Height
• Alternative size versions
• Alternative formats
• Latitude/Longitude of photos to be used by the client
• Creation/Last Modified Time
• Upload Time
• Mime Type

Etc.

[j4y-funabashi]

Currently my media endpoint returns the following when I call it with q=source

{
    "items": [
        {
            "url": "https://media.funabashi.co.uk/2019/vid.mp4",
            "mime_type": "video/mp4",
            "date_time": "2019-03-20T16:53:29.762421201Z",
            "lat": 53.800968166666664,
            "lng": -1.5413559444444442
        }
    ]
}

[manton]

I don't currently support this, but I just want to point to #14 here since the response should be the same for both. There was a discussion there about using published for the date so that it's consistent with other parts of Micropub. Here's what my response from the media endpoint with q=source looks like:

{
  "items": [
    {
      "url": "https://www.manton.org/uploads/2020/058fa92305.png", 
      "width": 1200, 
      "height": 816,
      "published": "2020-05-27T14:14:09+00:00"
    }, 
    {
      "url": "https://www.manton.org/uploads/2020/7a57980ca2.jpg", 
      "width": 1800, 
      "height": 1800,
      "published": "2020-05-20T02:22:09+00:00"
    }
  ]
}

[dshanske]

In order to address this, the initial agreement at the Micropub Popup 2020 was to require on upload a response that included a url property only. Any other properties are still pending for discussion, but suggested that it be considered based on prior art of EXIF properties.

[aaronpk]

Copying notes from the wiki:

---

Content-Type: application/json

{
  "url": "https://media.aaronpk.com/filename.jpg"
}

This response currently produced by:

• aaronpk in his media endpoint on media.aaronpk.com
• myfreeweb in [https://indieweb.org/sweetroll sweetroll] — instead of "url" there's a JSON structure with a bunch of stuff. For photos: "width", "height", "meta" (metadata extracted by exiv2), "palette" (prominent colors via vibrant), "tiny_preview" (data uri of a tiny WebP preview) and most importantly "source" (links to the actual image in different formats).
• WordPress Micropub currently returns the parsed metadata about the media file and the alternate sizes currently generated by WordPress on a file upload. It is not specifically reformatted for Micropub at this time.
• cleverdevil added support for this response in Known in November 2018.

And consumed by:

• aaronpk - a iOS Workflow that I created to upload to my media endpoint requests a text/plain response and uses the body as the URL, copying it to the clipboard. that was easier than adding a JSON parser to the Workflow.
• myfreeweb - sweetroll does rich photo display based on the data generated by the endpoint.

[dshanske]

Looking at Exif 2.32 http://www.cipa.jp/std/documents/download_e.html?DC-X010-2020, which is the latest version and makes some changes.

EXIF has 3 time properties

• DateTime - the last modified time
• DateTimeOriginal - when the original was generated
• DateTimeDigitized - when the original was digitized

Suggesting that updated might take the place of datetime.

Other potentially useful properties to start

• Description
• Artist
• Copyright
• Latitude/Longitude/Altitude
• Width and Length(EXIF uses length as opposed to width and height)

There are other properties, such as lens, camera make/model, ISO, aperture...

And this only covers photos...

[manton]

Micro.blog now returns url in JSON from the media endpoint when uploading. The url matches the value in the Location header. If you're uploading video, Micro.blog also generates a poster frame and returns that too:

{
  "url": "https://manton.org/uploads/2020/example.mov",
  "poster": "https://manton.org/uploads/2020/example.png"
}

[manton]

Bumping this since @dshanske mentioned it in chat… I'd be in favor of adding image width and height as simple fields in the JSON response, but I don't think we need to include every possible bit of metadata there.

[dshanske]

Agree about every piece of metadata. I'd like width, height, and dates...and to address the question of multiple sizes the server might generate. Many services have the concept of a thumbnail version in their returns, but it isn't consistent. @manton commented in chat that Micro.blog returns a 400w thumbnail for images. Because of different sizes/shapes of images, there is no good answer.