Question #1517
closed
decide on/implement content negotiation for image API
Added by Christoph Hoffmann over 3 years ago.
Updated about 3 years ago.
Description
the image retrieval API implemented in #1280 should conform to server driven content negotiation conventions
the standard currently only covers format negotiation, all other features (size, resolution, width) are still experimental
- format negotiation should go, as described in the Accept Header (but could then also be replaced/overridden by a query parameter for ease of use)
- size negotiation should (as I understand is already implemented) remain in the path parameter, fixed to the preconfigured named sizes
What would this implementation enable?
- the user/client would, simply by passing a mime type as a parameter/header, be able to retrieve the originally uploaded resource or a client conforming format
- in scenarios where the client would not pass an explicit format request, the browser would still add standard accept headers we can work with
- Description updated (diff)
- Category set to API
- Status changed from New to Acknowledged
- Assignee set to Bernhard Koschiček-Krombholz
Should we try to implement the experimental width accept header?
I will try to make this happen with the new version 6.3.0.
re the width header: I am definitely up for giving it a try, but I must say I have never seen this implemented in an API (as opposed to Accept etc)
there is however another issue: if we let the user freely select the width of the resource, this could,
- in case it is cached, mean that a lot of space is occupied, or,
- if it is not cached, that it consumes a lot of resources (depending on the original size of course)
for a cached solution I suppose a pruning script would be inevitable at some point
@Alexander Watzinger?
The solution for the resizing function for the API is at the moment caching. The image is stored in a temp folder which will be cleared after the request.
Even if the user can select the width, it can not be larger than the original size.
Meeting 01.06.:
API should be not allowed to dynamically created. (delete the code)
The /api/display/ path will get new parameter named image_size which will take 'overview', 'thumbnail', 'table', 'icon'.
Within the content endpoint, there will be the information which size 'overview', 'thumbnail', 'table', 'icon' is set in the OpenAtlas instance.
Points of the meeting are implemented.
- Status changed from Acknowledged to In Progress
- Status changed from In Progress to Resolved
Had a meeting with Christoph. Since it is right now not possible to convert media files (pdf, mp4 etc.) to images due to security reasons, there is no need for additional content negotiation. Size parameters are implemented but in feature_image_processing branch.
- Target version changed from Wishlist to 208
- Status changed from Resolved to Closed
- Tracker changed from Feature to Question
- Target version deleted (
208)
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by