Question #1517
closed
decide on/implement content negotiation for image API
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
Updated by Christoph Hoffmann almost 3 years ago
- Related to Feature #1426: API: Display image smaller size added
Updated by Christoph Hoffmann almost 3 years ago
- Related to Feature #1492: Image Processing added
Updated by Bernhard Koschiček-Krombholz almost 3 years ago
- 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.
Updated by Christoph Hoffmann almost 3 years ago
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
Updated by Bernhard Koschiček-Krombholz almost 3 years ago
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.
Updated by Bernhard Koschiček-Krombholz almost 3 years ago
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.
Updated by Bernhard Koschiček-Krombholz almost 3 years ago
Points of the meeting are implemented.
Updated by Bernhard Koschiček-Krombholz almost 3 years ago
- Status changed from Acknowledged to In Progress
Updated by Bernhard Koschiček-Krombholz almost 3 years ago
- 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.
Updated by Bernhard Koschiček-Krombholz almost 3 years ago
- Target version changed from Wishlist to 208
- Status changed from Resolved to Closed
Updated by Alexander Watzinger over 2 years ago
- Tracker changed from Feature to Question
- Target version deleted (
208)