add vis/uuid/static/:w/:h.png

[javisantana]

this new endpoint should redirect to the named map url.
so

https://rambo-test.cartodb.com/viz/ed64a3de-fd42-11e4-8ae4-0e49835281d6/static/width/height.png

redirects to

https://rambo-test.cartodb.com/api/v1/map/static/named/tpl_d64a3de_fd42_11e4_8ae4_0e49835281d6/width/height.png

The redirection should have cache headers and should return both http and https versions

Ideally it should redirect to CDN url version of that assets but I'm not sure we have that information in rails process

https://cartocdn-ashbu.global.ssl.fastly.net/rambo-test/api/v1/map/static/named/tpl_d64a3de_fd42_11e4_8ae4_0e49835281d6/width/height.png

Branch: 4153-static-maps-redirects

[javisantana]

if you feel strong enough add it to current milestone

[Kartones]

No Pain No Gain -Lo Wang

[luisbosque]

We could have the target url to be a template in app_config.yml. For example:

https://:username.:domain/api/v1/map/static/named/tpl_:id/width/height.png

This way the user can choose to add a CDN url or any other publishing url.

Just a idea

[javisantana]

@lbosque we use something like that in cartodb.js (and cartodb) https://github.com/CartoDB/cartodb.js/blob/develop/doc/API.md#how-to-set-a-different-host-than-cartodbcom

[luisbosque]

That's right. So, the idea is that we set that url/template as configuration in app_config

[Kartones]

+1 to the config-based template, will do it

[Kartones]

@javisantana Small doubt:

Format of the input urls is going to always be
{protocol}://{username}.{domain}/viz/{id}/static/{width}/{height}.png ?

No organizations, no subdomainless versions, etc.? I must know that in order to skip all subdomainless, etc. logic or keep compatible with it.

Also note we're not versioning at that URL, it is not an issue but a remark just in case.

[Kartones]

Config and output value:
app_config.yml -> defaults: -> static_map_template: '{protocol}://{username}.{domain}/api/v1/map/static/named/{tpl_id}/static/{width}/{height}.png'

Where {tpl_id} is calculated from {id} using existing Named Maps logic (just some string juggling)

[javisantana]

there are different things here:

How to configure CDN

• if maps_api_cdn_template is present use the url to create the final static image url.
• if not present maps_api_template from Cartodb.config is used so subdomainless urls will work too

This url is in the form:

{protocol}://{user}.cartodb.com

or

{protocol}://zone.cartocdn.com/{user}

some requirements:

• it does not contain information about the service
• please, user {user} and not username to keep everything homogeneous

in this way we can use CDN for maps api for stuff like layergroups, not only static image.

Service URL

In general everything it's public api should be under /api/vX, so embeds, static images, viz.json, tilejson and so on should be there.

for static images:

{protocol}://{user}.{domain}/api/v2/viz/{id}/static/{width}/{height}.png

for viz.json:

{protocol}://{user}.{domain}/api/v2/viz/{id}/viz.json

and in the future we have:

for embeds (embeds should be api too):

{protocol}://{user}.{domain}/api/v2/viz/{id}/embed.html

for tilejson:

{protocol}://{user}.{domain}/api/v2/viz/{id}/tile.json

for exporting:

{protocol}://{user}.{domain}/api/v2/viz/{id}/export.zip

[rochoa]

❤️ the Service URL proposal.

So my money in this issue goes with:

• Expose in rails a URL like:

{protocol}://{user}.{domain}/api/v2/viz/{id}/static/{width}/{height}.png

• That either redirects to:

{protocol}://{user}.{domain}/api/v1/map/static/named/{tpl_id}/{width}/{height}.png

• Or applies the maps_api_cdn_template logic if present, something like:

{protocol}://{zone}.cartocdn/{user}/api/v1/map/static/named/{tpl_id}/{width}/{height}.png

Basically I'm agreeing on @javisantana proposal.

[Kartones]

Perfect! Just one thing: Careful with /api/v2/viz/, our current versioning schema is: First version of everything goes to v1, new versions incompatible go go v2, v3, etc. So Rails route should be like:
{protocol}://{user}.{domain}/api/v1/viz/{id}/static/{width}/{height}.png.

I can override this convention if you really see it important, but else I'd go with v1.

And that self-answers my question of if I have to support subdomainless, etc. (yes as is another proper endpoint of /viz/)

[rochoa]

Why /api/v1/viz?

I mean, if we already have /api/v2/viz and we are adding new features, why are we adding the to the /api/v1/viz?

I can understand that if we had a new API, let's say /api/v1/wadus then it should go with v1 but in this case we are adding a feature to an existing API, aren't we?

[Kartones]

Ok, all solved (via chat): As the public-facing part of the API is just the vizjson, ok and clearer to go with v2 for the new endpoint.

[Kartones]

And now, the big question: Privacy

Should the endpoint require auth for retrieving non-public visualizations? I guess yes, because else is a quick way of exposing a screenshot of private maps if you somehow catch the uuid.

[javisantana]

privacy as always: using api_key you get the private+public+link ones and without it only public+link

Do you see any case where you want to see a private viz shot?

[Kartones]

not initially, but I was thinking if for the dashboard... but then I can allow session auth too and no need for private key, so is not a concern, I just wanted to confirm.

[Kartones]

I missed the varnish cache and forcing same protocol that comes in the request, so adding that now