Viewing last 25 versions of post by Rene_Z in topic Philomena open beta / breaking API changes

The new API no longer returns the @`mp4@` representation for images uploaded as WEBM.


 
Example: "[Old API":](/1482281.json), "[New API":](/api/v1/json/images/1482281

)
 
For images uploaded as GIF, the new API still returns both the @`webm@` and @`mp4@` representation as before (["Example":](/api/v1/json/images/1147843])).


 
Is this intended behaviour? WEBM still isn't as widely supported as MP4, so I'm relying on the MP4 representation (in my case sending the image to Telegram, which supports sending MP4 videos but not sending WEBM videos). Of course I could just change the file extension in the URL, but that would be quite hacky and I'd have to check if the MP4 actually exists each time.


 
**EDIT 2**: I noticed a second issue. The API now always returns the `mp4` and `webm` fields for GIFs, even if the video versions don't actually exist on the server (for old uploads where no video version was generated). The URLs just return 404. This was not the case before, it would just not include the video representations in the response. However, it seems that even the old API now returns those non-existant representations.
 
Example: [Old API](/232093.json), [New API](/api/v1/json/images/232093)
 
**EDIT**: And a minor issue with the API documentation, the @`format@` field of an image response can also return @`jpeg@` (instead of @`jpg@`), depending on the original file extension of the image. The behaviour is the same as with the old API, it's just missing from the documentation.

The new API no longer returns the @mp4@ representation for images uploaded as WEBM.

Example: "Old API":/1482281.json, "New API":/api/v1/json/images/1482281

For images uploaded as GIF, the new API still returns both the @webm@ and @mp4@ representation as before (["Example":/api/v1/json/images/1147843]).

Is this intended behaviour? WEBM still isn't as widely supported as MP4, so I'm relying on the MP4 representation (in my case sending the image to Telegram, which supports sending MP4 videos but not sending WEBM videos). Of course I could just change the file extension in the URL, but that would be quite hacky and I'd have to check if the MP4 actually exists each time.

*EDIT*: And a minor issue with the API documentation, the @format@ field of an image response can also return @jpeg@ (instead of @jpg@), depending on the original file extension of the image. The behaviour is the same as with the old API, it's just missing from the documentation.