is_supported should follow rediects

[EmilStenstrom]

I just tried to embed a couple of bit.ly links on your site, and they worked fine, resolving the redirects and returning an embed code for the resulting url. I was confused when is_supported didn't work that way, and instead returned that the link was not supported. So this is my feature request, make is_supported support redirects.

[screeley]

Going to mark this one as a won't fix. It's impossible for us to list every link shortener out there, so instead you should just send a request to Embedly.

Technically speaking, every url is supported by Embedly. is_support is only if you want to limit urls to these domains: http://embed.ly/providers.

I would avoid using is_supported if you are going to be sending shortened links.

[EmilStenstrom]

I'm not asking you to list every link shortened out there, sorry if that was unclear. I'm asking that the Python library follow redirects (using a HEAD request for instance) before checking against the list of supported URL:s.

I've solved this locally by subclassing the Embedly class, but since your site does this automatically I think people will expect the same of the Python API.

import requests
from embedly import Embedly

class CustomEmbedly(Embedly):
    def is_supported(self, url):
        response = requests.head(url, allow_redirects=True)
        return super(CustomEmbedly, self).is_supported(response.url)

[screeley]

In this case you are just duplicating calls to that URL. You are now making two HTTP requests for every call to Embedly instead of one. This will work for your use, but not something we will add to the library as a whole.

You can also just check the type on the way back if you would rather Embedly do the head request for you.

import embedly
client = embedly.Embedly('KEY')
obj = client.oembed('http://bit.ly/h7llGD')
if obj.type in ['photo', 'video', 'rich']:
     # use
else:
     # don't

[EmilStenstrom]

We are duplicating calls, but since the response is cached and this is done async it's not that bad.

We are using your method of filtering the returned url types, but each call to you is charged so to keep our costs down we want to filter out the non-supported links first. I guess the optimal solution (for us) would be if we sent the types to you, and you only charged us (and returned data) when the link matched the supplied types.

[screeley]

Sadly we still have to do the work of fetching every URL you send to us, so it's cost prohibitive on our side to offer that as a feature.

You seem to have figured this out on your side, best of luck!