0

LastFM API used to expose "Cache-Control" header in HTTP answers. Instead here is what I got:

curl --head "http://ws.audioscrobbler.com/2.0/?api_key=APIKEY&artist=NOFX&autocorrect=1&format=json&method=artist.getsimilar&results=100"

HTTP/1.1 200 OK
Server: openresty/1.9.15.1
Date: Wed, 13 May 2020 09:44:27 GMT
Content-Type: application/json
Connection: keep-alive
content-length: 81358
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Origin: *
Mandats-contributions: 86400

Since last.fm "term of use" require us to implement some kind of caching (which is sensible for any kind of use on the web anyway), I'm wondering: how do I implement it with such answers?

When I noticed "Cache-Control" header disappearance I forced an hardcoded cache of 1 month in the code overriding the regular "Cache-Control/Etag/…" caching logic.

I may have overlooked something here, I'm no expert. But I hoped there was a better solution than keeping a static 1 month cache.

kaliko
  • 101
  • 4

1 Answers1

0

I got a response from last.fm but that was posted on their previous support platform getsatisfaction which ended the service quite abruptly. Then I don't have the exact wording of the answer since I don't even have the source.

To sum up, they answered they have no plan to provide any cache friendly tags.

For the last 10 years, i've been wondering how long will they support their web services, I've been lucky for the past 10 years to keep using them. But for sure one should not rely on last.fm. I hope listenbrainz will manage to provide a open alternative to last.fm :)

kaliko
  • 101
  • 4