Bug overview description.
So I've made a little tool yesterday (see forum #265232 for details) that uses the API data for implications and aliases to generate graphs, and I must be the first person to use those routes because they are complete garbage. I found out that not only is the output inconsistant between the two (implications returns the tag ids for both tags, the id of the implication itself and the pending status; aliases returns the name of the aliased tag, the id of the tag it's aliased to, the pending status and the id of the implication) [jesus fucking christ], but aliased_to and implied_to don't actually give you the results for full matches, they give you the results for any partial match in both directions (you'd think a parameter like aliased_to=red would not give you the aliasing rules from armored), which means I spend a lot of my runtime fetching tag data at the rate of one tag per second just to clean up what the API sends me (not to mention both of those routes are arranged in pages of 20 implications/aliases each, which is doubly annoying).
What part(s) of the site page(s) are affected?
The JSON and XML API routes for both https://e621.net/tag_implication/index and https://e621.net/tag_alias/index.
What is the expected behavior?
The routes should have parameters that allow direction-sensitive search of exact tag names, and have the results for both contain the names and IDs for both predicate and consequent tags, possibly with the same data structure for both.
What actual behavior is given instead?
See bug overview. Both API routes provide little useful data, making it neccesary to cross-validate the tag ids with tag data from the API, which makes the whole process longer.
Can you reproduce the bug every time?
Yes.
What steps did you take to replicate this bug?
See overview.
Updated by Chessax