5

I'm declining this, not because I don't see the merit in it, but because we don't have the data to return in anything approaching a reasonable time. Our badge awarding code is very complex, and intentionally run in staggered (and even, in some cases, random) schedule to prevent DOS-ing our own databases. Opening those queries up via an API would be ...


3

Categories aren't sufficiently stable to expose in the API. It is entirely possible (even likely, in my opinion) that we'll revisit and rework the proposal categorization significantly in the coming year.


2

No, we won't be implementing this. Not that I don't see a use case for it, but we'd never be able to accept and execute arbitrary regular expressions against the database. It'd just be far too easy cripple performance wise (we've done this accidentally plenty of times, and we don't have to worry about malicious actors on the dev team). While we could ...


2

The problem with this isn't so much the security (though that's a concern), it's that we don't want the backwards compatibility constraints such blessed installations imply on our HTML and javascript. As such we're unlikely to ever do something like this, so I'm status-declined-ing it.


1

This is by design, for reasons of technical limitations. Unfortunately, we don't have easy access to display names at a "network level". What's available (and what's backing the API) is very normalized, often somewhat delayed, data. As a rule, only very small bits of data are pulled into global tables; as it all has to reside in a single database. ...


1

This was dropped intentionally. The problem is that maintaining this sort of meta-api is both intensive (lots of v1.1 was spent not breaking v1.0 because of the way introspection was working) and of very little utility. Yes, it's useful for generating wrappers; but those wrappers are written once per version, and not updated meaningfully. If we were ...


1

You shouldn't be making more than 4 requests in this case. fetch a page of /users/{ids}/timeline group the ids by type (question, answers, comments) since the max pagesize fo users/{ids}/timeline is 100, we know there are < 100 of each id* make 1 query each with the appropriate ids to /questions/{ids}, /answers/{ids}, and /comments/{ids} This is the ...


1

There actually isn't much sensible that we could return as a "relevance rank", what we essentially get out of Lucene is just the order of posts to return. Internally, relevance ordering doesn't make sense to compare across separate invocations of the same query much less across different queries or even sites. Our search infrastructure is also subject to ...


1

The Sexuality site was an experiment, one which failed. We may revisit this in the future, but for now there's no point in the flag as it's one use case is gone.


1

Perhaps a good approach would be to cache the entire list of tags on a site (there are only 770, or 25 pages worth on Travel.SE). You can then run them through a RegEx locally. Tags don't change very much so you could just refresh your list every week or so to keep it up to date. You didn't specify a particular language / framework, but if you were using ...


Only top voted, non community-wiki answers of a minimum length are eligible