Image URL from catalog/products/{productId}

Why such a ugly & big url for the images when you can use the url: ? eg:

“ProductId”: 24348,
“ProductName”: “Tutan Mask”,
“Image”: “

when you can use:

for the same result.

Although I don’t necessarily disagree with you, does it really matter?

Totally understand where you’re coming from. We’re reworking our CDN right now; so it may make sense to expose the pointer instead of the direct link … and you don’t store it. However, as @arjen mentioned; it shouldn’t matter as long as you’re using the link when you’re using the API. One arguement would be “less characters”; which is valid at scale. :slight_smile:

Less characters - for MTG - means a win of 2MB in the DB for all the cards.

In my case, at least, I do fetch all your info and store it locally so my users can make search while they don’t have a internet connection and to have this static info locally is always a faster & better experience, while it also saves you a lot of server costs :slight_smile:

That said, the direct link may change, for numerous reasons and as you just pointed that you are working on the CDN and the direct link therefor may change in the near future, which then will invalidate the stored links.

If the approach was to have the pointer instead, this problem will not matter since the pointer will automatically point it to the correct direct link.

Also, if well documented the pointer link itself may be omitted and the dev’s themselves would just have to sum the pointer url plus the name of the image.

In the end, this could be just: {"ImageName:" : "24348_200w.jpg”"}

We would save storage, reduce response times and server costs.

What are your thoughts if we were to expose multiple image sizes so that you could pull the correct one for thumbnails … and card scanner applications could pull our high-quality version to generate image descriptors from? I know this is actually walking away from ‘less characters’; but we want to offer the correct solution.

We could also build an additional endpoint just to get the “media” for a product.

Good question, but there is no obvious answer.
It will depend on what you want to achieve.

Lets see what others are doing. Scryfall for example, they don’t give a shit about performance, they just have 1 endpoint for a cards info data which also has the price of it and links to everything from the cards images (small, normal, large) to every store where you can buy the card. It’s just a big response.

If you have saved all the cards data, you need to call this api endpoint to fetch the price and therefor receive unnecessary info, but if your app goal is not to save anything and fetch data every time as users use it, it may make sense to have all this data fetched from 1 api call.

But again, if a user is accessing the same card over and over, you will have unnecessary info fetched without any need. If you multiply this for hundred of thousands of users you are wasting a lot of traffic data, response times and server costs. I do not have the data for how many users/requests are being made and neither the server costs, but I wouldn’t do it this way.

That said, the answer to you question depends if you want to make the api for user to save the data on their apps or to have it being fetched every time a users search’s the card on their app.

Then, it also depends on the way you want to document suff.

So, I have four answers for you:

1 - Easy way:

  "imageURL": {
     "small": "",
     "normal": "",
     "large": ""

2- The low characters way:

  "imageURL": {
     "small": "24348_30w.jpg",
     "normal": "24348_200w.jpg",
     "large": "24348_420w.jpg"

3 - The, I want to save as many characters as possible way:

I would create for every card in my system a _30w version (thumbnail), the normal _200w and the original version (the big image) with no width at all, all this images would have the ID of the card with the correspondent _000w, I would write this on the documentation of the API and devs would just have to use the ID (which always comes in the API endpoint) with the Pointer URL to fetch the image that they which.

4 - The, I want save server costs as much as possible:

Use the 3 option and:
Create the media api endpoint - give access just to the devs that have scanners - for the HD image and have devs save it for their intended purpose (I personally don’t need HD images for my Scanning Engine to work ) of creating the descriptors. I wouldn’t like that devs would use the HD images on their app evey time a users access a cards info. If I did this in my apps would generate terabytes of downloaded images each month.

PS: Just a thought. For better server/data management, this may be better:

  "imageURL": {
     "small": "",
     "normal": "",
     "large": ""
1 Like

I like this format a lot; it reminds me of the old Flickr integration (which I recall as being very simple). We will have to expand on it a bit since we have more than just sizes to contend with (ie; flip cards, marketing images, “scanner” reference images, etc.)

Hate asking this nearly 2 years later :). However, I don’t see anywhere in the API on how to get the larger image (greater than 200px wide). Options?

Update the latest image links returned by the API to be 400w instead of 200w and it’ll use high res. Note that this largely only works for Magic: the Gathering cards.

Joshua -

Thanks for the insight. I tried on random Pokemon cards and it worked wonders; thanks!