Display assets on third party web application

Help
1

Hi,

To help our clients organize content we are creating admin panel. We need to show thumbnails and original assets in our web app.

Should we duplicate assets on our side for the preview, or there is way to get asset url from API?

2

You can’t get the original url for download, but you can use the API to get a configurable thumbnail url for your assets. A call like this:

curl -u:$API_KEY https://info-beamer.com/api/v1/asset/list

will return a JSON structure with information about each asset that looks like this:

   {
      "filename": "example.jpg",
      "filetype": "image",
      "id": 44821,
      "metadata": {
        "format": "jpeg",
        "height": 1080,
        "width": 1920
      },
      "size": 670495,
      "tags": [],
      "thumb": "https://cdn.infobeamer.com/dynimg/blob/image~tI8Hi0FBQAtuoJ-qOsOv4w~cVvrD-5D",
      "uploaded": 1548155311,
      "used": 0,
      "userdata": {}
    },

The thumb value is a url where you can request a thumbnail from. By default the returned is 64x64 pixels. You can specify other size by appending the size= url parameter. So like this:

[..]/blob/image~tI8Hi0FBQAtuoJ-qOsOv4w~cVvrD-5D?size=256

See also https://info-beamer.com/doc/api#thumbnailurls

3

Thanks for fast replay,

I was aware about thumb field from asset list.
Our use case is that we would never need full asset list.
EG. We will have 1000 different client groups, and they should be able to see and manage only assets uploaded by members of their group.
On successful API call of “Upload Asset”, we will store asset id on our end, and link it to appropriate user group.
That way we would not need to ask for “List all assets”, but will know exactly what assets we want to show.

The problem with this approach is that we can not store thumbnail response from “Upload Asset” call because:
“Thumbnail urls: These urls point to a webservice that provides thumbnails for assets. You should not cache the returned urls as they might change”

We could also attach userdata on asset but than we would ask you for every time to list all assets just to filter and show 1% of them.

If we can’t have original asset url that to implement preview on our website we need to store original asset on our end.

4

Interesting use case. I see two solutions:

  • storing the asset’s thumbnail data on your side by issuing a single asset/$ID call after an upload.

  • Alternatively you could setup a proxy service that allows your users to fetch /thumb/$ASSET_ID/$UPLOADED.jpg from your service with $ASSET_ID being the asset’s ID and $UPLOADED being the value of the uploaded field in the asset detail response you’d do after each upload. Later you’d do a fairly cheap /asset/$ASSET_ID call to info-beamer when an uncached thumb is requested, fetch the image referenced by thumb and can instruct the client to cache the response forever as it will never change. There is a minimal race condition in there if the same asset is overwritten at the same second twice though. Right now the API semantics doesn’t have a better way to handle this. This might actually be something to improve in the future.

Is there any overlap between your client groups? So do they share assets or are they all using their individual assets/packages/setups? If so, another approach might also be to use the normally disabled sub-accounts feature. That way you’d have a master account and can create any number of full featured sub-accounts. They share nothing and each is a full account you could assign to each client. The master account is responsible for billing and can jump into any sub-account. Depending on how you structure your application, this might make it easier to avoid accidentally exposing data between clients as each then has its own API key.

5

Thinking about this a bit more: How does the following suggested change sound?

  • The validity of a returned thumb url is increased to at least 30 hours

  • The /asset/upload call returns the asset information directly, so there’s no need to call /asset/<id> after an upload.

Together the following would be possible: For each upload you save the returned value of thumb in your database. If a user requests an asset, you can directly use that to build a thumb nail url without consulting the info-beamer backend.

Every 24 hours you do a single /asset/list call to update all the stored thumb values in your DB for all assets, basically ensuring they continue to be valid for at least the next day.

6

Hi,

Thanks again for the proactivity.
Prolonged validitiy of thumb url would solve the thumbnail problem.

For the preview of the original asset we would still need to duplicate it.

7

Ok. Consider the thumb urls to be valid for 30 hours from now on. This actually has basically been true for most of the past 4 years, except it was never explicitly mentioned as a shorter validity makes it easier to modify the implementation in the backend or react to fubar’d responses (like blank images due to some error). The documentation will reflect this change in the next few days.

8

The documentation is now up to date: https://info-beamer.com/doc/api#thumbnailurls

Happy asset thumb caching!

1 Like