Not 100% sure if this is the correct forum to post this in but here it is nonetheless.

Looking through the API docs in the wiki I was wondering if there's any standardized format available that I can use to build out an API client.

Lots of apps use Swagger or ReDoc for documentation lately which is backed by an OpenAPI spec that gives some schemas for request arguments and response bodies that make it super easy to build out a client.

Is there something like this available right now, and if not is there any plan for something to be added in the future?

Nothing like that exists right now unfortunately. The API is in need of a rework (maybe graphql?) anyways, what is available now is mostly designed to be consumed by the site itself.

The current API will stay as it is and will not go away but should a new API be designed in the future it will most certainly come with some sort of schema. There are no plans on when that might be though, so don't wait on it.

earlopain said:
Nothing like that exists right now unfortunately. The API is in need of a rework (maybe graphql?) anyways, what is available now is mostly designed to be consumed by the site itself.

The current API will stay as it is and will not go away but should a new API be designed in the future it will most certainly come with some sort of schema. There are no plans on when that might be though, so don't wait on it.

Gotcha, I'll work with what's available for now then.

Thanks!

Current wiki is not really updated (since the site update), I wrote some but that just a small part.
e6 is for the most part same as https://danbooru.donmai.us/wiki_pages/help:api

I don't want to spin off a new thread as I feel this might be slightly related.

I've been going through the API docs when possible but also pairing this with the developer tools in Firefox and the GitHub repo.

Currently most of the routes I need to use are open in the sense that I can just add &_client=Blah/1.0 to get responses. However, I've run into an issue when searching for tags that ends up forcing me to make two requests where the regular site only has to make one.

The route I'm referring to is /tags/autocomplete.json, which on the backend from what I can tell is just searching for regular tags then checking for aliases. I can implement this on my own client by spitting out two requests with the same query but on the paths /tags.json and /tag_aliases.json.

This isn't a huge concern for me as far as my development is concerned, I lose a bit of speed but I just spit out the two requests and merge them when I get both results which matches the behaviour of the other route exactly. My main concern here is as this scales it could end up being a bigger issue.

If this makes sense as a new thread let me know and I'll spin it off into a new one.

Is there a reason you can't use the /tag/autocomplete.json endpoint?

kiranoot said:
Is there a reason you can't use the /tag/autocomplete.json endpoint?

CORS from what I can tell, I'm trying to build out a web app so I can't override my origin or user agent headers. Both the /tags.json and /tag_aliases.json routes will allow me to make a request as long as I add _client=ClientName/Version to my query, the autocomplete route doesn't accept this for whatever reason.

oboythatsureisapenis said:
CORS from what I can tell, I'm trying to build out a web app so I can't override my origin or user agent headers. Both the /tags.json and /tag_aliases.json routes will allow me to make a request as long as I add _client=ClientName/Version to my query, the autocomplete route doesn't accept this for whatever reason.

I will look into fixing this. Looks like it's a misconfiguration somewhere.

kiranoot said:
I will look into fixing this. Looks like it's a misconfiguration somewhere.

Thanks, I appreciate it.

A quick addendum to this, would there be interest if I was to create an OpenAPI spec based on the GitHub repo then make a PR for it?

I've been spending a decent amount of time working with the APIs over the past few months and I'd like to think I'm pretty familiar with some of the core functionality at this point.

oboythatsureisapenis said:
A quick addendum to this, would there be interest if I was to create an OpenAPI spec based on the GitHub repo then make a PR for it?

Sure, that sounds like something useful. Though I think putting it in your own repo and linking there in the api wiki page (and mentioning it's third party) is a better idea. You can edit there at your own pace without having to wait for merging and it also makes it clear that it's community effort.

There are quite a few 'hidden' features which you can't guess at unless you look in the code, and a few surprising results under certain conditions. I can look over it when you've got something if you want and give you some potential corrections/missing endpoints.

There was an attempt at doing that for the new website around the time it came out, though it didn't get all that far. You may be interested in using it as a starting point, though.