Project

General

Profile

Question #1517

decide on/implement content negotiation for image API

Added by Christoph Hoffmann 5 months ago. Updated about 1 month ago.

Status:
Closed
Priority:
Low
Category:
API
Target version:
-
Start date:
2021-05-17
Estimated time:

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

Related issues

Related to Feature #1426: API: Display image smaller sizeClosed2021-04-02Actions
Related to Feature #1492: Image Processing Closed2021-04-01Actions

History

#1

Updated by Christoph Hoffmann 5 months ago

  • Related to Feature #1426: API: Display image smaller size added
#2

Updated by Christoph Hoffmann 5 months ago

#3

Updated by Christoph Hoffmann 5 months ago

  • Description updated (diff)
#4

Updated by Bernhard Koschiček-Krombholz 5 months ago

  • Assignee set to Bernhard Koschiček-Krombholz
  • Status changed from New to Acknowledged
  • Category set to API

Should we try to implement the experimental width accept header?

I will try to make this happen with the new version 6.3.0.

#5

Updated by Christoph Hoffmann 5 months 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

Alexander Watzinger?

#6

Updated by Bernhard Koschiček-Krombholz 5 months 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.

#7

Updated by Bernhard Koschiček-Krombholz 5 months 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.

#8

Updated by Bernhard Koschiček-Krombholz 4 months ago

Points of the meeting are implemented.

#9

Updated by Bernhard Koschiček-Krombholz 4 months ago

  • Status changed from Acknowledged to In Progress
#10

Updated by Bernhard Koschiček-Krombholz 4 months 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.

#11

Updated by Bernhard Koschiček-Krombholz 4 months ago

  • Target version changed from Wishlist to API
  • Status changed from Resolved to Closed
#12

Updated by Alexander Watzinger about 1 month ago

  • Target version deleted (API)
  • Tracker changed from Feature to Question

Also available in: Atom PDF