Bing Image Search API v5 - contentURL Redirect

Question

I hope you could help me, I'm trying to use the Bing Image Search API and everything is fine so far, there's just one thing that I don't understand, contentURL is a redirection, where should be the image url from the source website at least thats what documentation says (and the previous version of the search). I tried with Trending images and there the contentURL is how it should there. So only for Images search gives a redirection:

contentURL from first object of jSON Response

"contentUrl": "http://www.bing.com/cr?IG=9BF011209A7349ACAE17F77A728C2EBB&CID=26ACC54E26896146357ACC8E27B86066&rd=1&h=mgBegiuCUD3JUTxAAdzTjPyARNluGjEKSz9UCvuA2oM&v=1&r=http%3a%2f%2f2.bp.blogspot.com%2f-hqcXd4UtCrE%2fTqlVvAt7XJI%2fAAAAAAAAB54%2fw6WemH9gecU%2fs1600%2fcar%2bwallpapers%2bhonda%2b194.jpg&p=DevEx,5008.1",

This is my request:

https://api.cognitive.microsoft.com/bing/v5.0/images/search?q=car

I used Open API Test Console, just to verify that there's nothing wrong with my code, and the results are the same. Anyone encountered this or know how to fix it? I need the original url of the image in the case.

PS. I can cut the string and take the main address, but I don't think this is a good idea, because if it's a bug or they change it, it won't work, so is there a way to get original URL of the image?

Answer 1

The redirect is correct, it’s a simple url-encoded value that contains the external url (the redirection and encoding, ensures that any clicks are “logged” by bing).

The Url-decoded value from looks like this:

http://www.bing.com/cr?IG=E41AC580710C4720926F96345526C51D&CID=1D6FFCFA71F06E832A4BF53B70C16FAF&rd=1&h=crkRecXRYiREPeC5H-F6dhRSBUx0irVFTGzBmAo3qMk&v=1&r=http://2.bp.blogspot.com/-WtdFq_e6eKo/TV5W5s-hS-I/AAAAAAAAAvM/gmCUYOx3bX8/s1600/Animals_Cats_Small_cat_005241_.jpg&p=DevEx,5008.1

Answer 2

Patrick is right. Encoding the URLs is the industry standard best-practice for improving the relevancy of search-engine results in real time, thus increasing the value of the service without needing to increase its cost. It does however, present a necessary tradeoff which is the cause of the problem you've described.

That said, the return URLs appear to be designed to keep encoding in a consistent and predictable format. I have personally parsed >1k links to plaintext and, by implementing a few simple rules, have not yet created a single invalid link. You raise a good point about the potential for future changes, however as of now there hasn't been any indication they're going to change the format, and the URLs are currently relatively trivial to parse to plaintext.