5

The Stack Exchange API uses filters to determine which fields have to be returned from the service. The filter property is quite obscure though.

You can create the filter using the documentation pages of the API, for example here. I checked some fields to be included, but I don't know which any more. Also it is quite some work to do this for all endpoints in the data model.

I am using the Stack Exchange API for building a realtime version of SEDE (you can find it here, pick Stack Exchange from the list). I want to add all entities to it, but I have to go over each and every page, check all the check boxes and copy the filter.

Then I wondered: if SE can disclose the way the filter is calculated, I don't have to go over every page. Instead I can calculate the filter on the fly and pass it in (I know you can call /filter/create but adding an extra call to every call seems to make no sense).

So the question: can SE disclose the way the filter is calculated? Is there an easier way to include or exclude fields?

Improve this question
5
  • I'm pretty sure there's a post on StackApps about this somewhere
    – Cai
    Oct 24, 2016 at 16:10
  • @Cai you mean this one?
    – rene
    Oct 24, 2016 at 16:19
  • @rene I don't think that's the one I meant but that certainly gives the answer :)
    – Cai
    Oct 24, 2016 at 16:20
  • 2
    from the blog: The point of bit shuffling is to make it both harder to figure out the implementation so such “too clever for your own good” behavior is harder to pull off, and to really drive the point home that you shouldn’t be creating filters without calling /filter/create.
    – rene
    Oct 24, 2016 at 16:31
  • I know I suggested this @Pat but in hindsight it looks like this will be a fruitless attempt. I think you're stuck with creating the filters once on your own.
    – rene
    Oct 24, 2016 at 16:34

2 Answers 2

Reset to default
5

API filters are guaranteed stable, so you can generate them offline and embed them in your app (you don't have to fetch from the api prior to each call). Equivalently, you can just cache the filters you dynamically generate.

We don't disclose the generation method because it may change in the future. Should that happen we'll still guarantee every filter we've ever issued continues to work (again, guaranteed stable), but anybody who's generating them without /filter/create calls would be out of luck.

Improve this answer
6
  • 1
    Would it hurt/ have negative effects if you would create one filter which includes all fields from all types and use that filter on all endpoints?
    – rene
    Nov 7, 2016 at 21:00
  • So if I understand correctly I have to go over each endpoint manually and create the filter? This means that I always will go for the maximum available filter because else I have to register each combination of fields separately. Is this a problem for your database load?
    – Patrick Hofman
    Nov 7, 2016 at 21:38
  • (I asked this to minimize the load on the server. Any other suggestions?)
    – Patrick Hofman
    Nov 7, 2016 at 21:39
  • @PatrickHofman filters are shared between all routes, they aren't pinned to a route (though the UI filters to what's actually returned by default, that's only for convenience; you can edit any type in it)
    – Kevin Montrose
    Nov 7, 2016 at 22:02
  • @rene an "everyting" filter is permitted, but the backoff throttle is calculateed dynamically based on how expensive a request was so they may harm your use. Requesting additional fields that aren't returned by a route has no impact though.
    – Kevin Montrose
    Nov 7, 2016 at 22:05
  • @rene You would need quite a lot of bandwith and nearly every single API call would tell you to back off (since "everything" includes items and total, the most computationally expensive fields to fill in). Other than that, I can't think of a negative effect.
    – SE is dead
    Jan 8, 2017 at 17:53
2

You can create the filter using the documentation pages of the API, for example here. I checked some fields to be included, but I don't know which any more.

The API has a route that will describe existing filters for you, /filters/{some-filters}. You can pass it a list of encoded filters and get back JSON representations of the filter objects.

This isn't exactly what you're looking for, but seemed to be worth pointing out.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .