Originally the API was basically 1:1 with Danbooru so any booru app could just say e621 was danbooru and bam, everything worked just fine. With the new changes, almost no booru apps work and will have to have a specific option for e621 just to retrieve posts.

So why change the API like this? From what I've seen so far there has been no added benefit, just unnecessary changes that break old functionality in apps that will more than likely not be updated.

Can anyone give me an answer on this?

caphistas said:
Originally the API was basically 1:1 with Danbooru so any booru app could just say e621 was danbooru and bam, everything worked just fine. With the new changes, almost no booru apps work and will have to have a specific option for e621 just to retrieve posts.

So why change the API like this? From what I've seen so far there has been no added benefit, just unnecessary changes that break old functionality in apps that will more than likely not be updated.

The old site was danbooru from 2007, the new site runs the latest danbooru, with a few changes.

I can't remember the exact reason for changing the API, but I generally prefer the latest one to code for, rather than having everything in one big list they're grouped properly, also little things like having the tags already be split into an array rather than one long string. Danbooru has tag_count_general and a tag string, whereas having an array of tags means you don't need the count as a separate value, you'd just use len(post['tags']['general']).

Then the Danbooru API has things like pixiv_id, which is irrelevant for E6, and other confusing bits such as large_url actually being the url of the sample image.

Personally I think it'd be better to have an improved API over an older one, if you stick to "make it compatible with everything" then nothing would ever get updated.

the enhanced tags object in the posts API is actually highly beneficial for third-party apps, since it's providing the categories of each tag without having to make another API call.

on the other hand, danbooru itself offers backwards compatibility: note that you can still access the old /post/index.json on dan, but not on e621.
maybe they're planning to implement it later.

bipface said:
on the other hand, danbooru itself offers backwards compatibility: note that you can still access the old /post/index.json on dan, but not on e621.
maybe they're planning to implement it later.

The old URL still returned the new APIs formatting, so rather than return data apps wouldn't be expecting it was set to return a 404.

It also had the benefit of decreasing load on the server, as it wouldn't have to process requests that the apps wouldn't be able to do much with, given the new formatting.

pup said:
The old URL still returned the new APIs formatting

on danbooru the old URL returns a different format to the new one

pup said:
[...] it was set to return a 404.

This caused a bit of a headache for me, because hard-deleted posts also return a 404. My program thought all posts were hard-deleted. Maybe this behavior could be changed?