maybe it’s a generational difference at work here but imagine this: we’re not going to wrap everything into JSON simply because we can.
people do all sorts of stupid things.
at work, i have to deal with an application (not just some random little thing, a major part of our production infrastructure) which - among other things - exchanges a lot of images between frontend and backend using base64-encoded messages sent through federated rabbitmq.
predictably, it works like absolute shit. it doesn’t scale. it’s also rather impressively fragile.
i’m not sure what went through deranged brains of people who invented this abomination but i suppose it was something like this: we’re already using rabbitmq to pass some data around, let’s use it for everything. oh it doesn’t support binaries? we’ll wrap them into base64. why not.
well, turns out, there were many reasons why not.
so yes, even though we’re using JSON on other api endpoints which provide structured text data, it doesn’t mean we should use it everywhere simply for the sake of uniformity.
the only kind of metadata for a favicon that would actually matter would be cache-ttl / last-modified information which is already sent through HTTP headers.
I’m using SDWebImage which works fine, but you can only GET an URL. To call getFeedIcon you need to POST data to the API which send back an image (or an error JSON).
I think I can update my code, but I’ve not updated the app since 2 years (but the app works fine, I’m using it every day ) and I need to refresh/update the code, so it will take some time.
As I said previously, I’m not going to update my server for now, so, for testing, if someone could provide me with a test instance with the latest API, that will be helpful for me. Thanx.