Tag Info

Hot answers tagged

7

Beta is an unusual time, in that the version number changes fairly frequently. Once we're into 1.0, such changes will basically never happen. You'll always be in 1.0, unless you explicitly target a newer version of the API; which will probably be rife with breaking changes, requiring much more than a recompile. As such, no discovery mechanism for API ...


6

For now, as we have only ~80 sites, you can set pagesize to 100 and get them all. But in general, I think pagination here makes no sense at all. Because there're no search parameters or ordering, I can't think of a situation where app can fetch only first page and be satisfied. Would it be possible to provide a way to search the list instead? I would ...


4

Have a look to the apps link on your Profile page *. * or follow this link


4

I had a similar issue a few months ago ago, and I came up with a couple of suggestions, one exactly like how you suggested: Ask the user for the email associated with their account, MD5 it, and compare it to the value provided by the API. This works, provided it isn't essential that the user is who he says he is - a users email may be publicly available, ...


4

There are two, rather divergent, answers to this question. First and foremost, its not in the API because nobody (us included, woops!) thought of it before the API interface was frozen... so it didn't get implemented, even as a trial feature. Perhaps we'll revisit it for a subsequent version. Alright, onto the real meat of the issue. Headers ...


3

Perhaps I can offer an opinion on cacheability of the API. Please don't downvote before reading through. Caching is hard Caching and cache invalidation is hard. Often, if not always, you need to intimately know the data to be able to cache it effectively. In order to enable a generic Etag caching ability the server will need to execute the request and ...


3

Are you by any chance using POST? For 1.0 this works. But not for 1.1 (though GET works fine for both 1.0 and 1.1). (I have no idea if it should work though.)


3

It has been more than 12 hours since I checked http://stackauth.com/1.0/sites, it is still returning a 404. Does anyone have an idea when http://stackauth.com/1.0/sites will be available?


2

This is because the user hasn't specified a username on those sites yet. The name you see on SuperUser, for example, is somehow derived from his/her OpenID.


2

Careers does not and will not expose the SE API. Thus it won't be listed in StackAuth.


2

Confirmed: http://stackauth.com/1.0/users/febfb878-3f6f-4215-9323-46d15d62ac7d/associated Edit: I discovered this affects StackCenter too. Some of my accounts show a funny blue picture because the email_hash isn't being passed along.


2

The appearance order of sites in /sites is non-determinant and should not be relied upon. On a personal note, using order of appearance as a grouping seems more complex than simply using a meta. modifier I am certain that you can depend on the api.xxx.com/api.meta.xxx.com pattern and can assemble your grouping or relations. And, no, i am no authority, but ...


2

The domain name is up for debate right now. Who knows whats going to happen


2

Actually, your browser does not download images on every request but perform a conditional request to the server using the If-Modified-Since header. In case the image is not changed, the web server returns a 304 Not Modified status telling the client "resource you are requesting is not modified, use your cache :)".


2

They are moving datacenters; could be related with that.


2

I've dug through the code (and recent networking changes) and found what I think is the issue. A fix has been deployed, but I'll need you to test on your end to confirm.


2

See the answer to the meta question Will all Stack Exchange sites look the same? To quote Robert Cartaino: When a site makes it out of beta, they will choose their own logo and design.


2

StackAuth does not currently have an API request limit. You really shouldn't be hitting it more than once a day though, for site information, and in accordance with general API guidelines for associated users. Both of which can be safely cached quite heavily. Eventually some sort of throttling scheme will be put in place.


2

We closed the Atheism site today - and I verified against the provided data dump that user 349 matches up. I strongly suspect this to be a caching issue that will resolve itself.


2

Joel is pulling some (non-malicious, but unusual) tricks with his OpenIds and e-mails. This has a nasty habit of tripping up association related code. Improvements are naturally ongoing, but its not surprising that he tends to find new edge cases for us. Anyway, this particular issue has been fixed, although as a consequence of his SO association being ...


2

This is relatively easy - just make him give you the same email address that he provided for his Stack Exchange account and then calculate the MD5 hash of the email address. Then compare that to the email_hash member of his account data. If the two hashes match, then the user is indeed who they claim to be. If not, they either provided a different email ...


2

I would think that simply the sites primary color and background-color would be more useful.


2

I found answer myself and posted in my blog post StackAlert Firefox Extension error key is not valid for passed access_token Solution in brief When you remove the application from StackExchange apps, and even after uninstalling the extension from Firefox, you will still have traces of that extension in Firefox. To make this extension work again, we have ...


2

This has been fixed. Site enumerations have changed alot behind the scenes in anticipation of Area51 sourced sites, and stackauth happened to get broken for a little bit.


1

This has been fixed.


1

How hard is it to remove "meta." from the api_endpoint and then iterate through the list of about a dozen sites you got already to find the one with a matching host name? In Objective-C, which is generally considered a verbose language, it takes maybe a dozen lines or so to be really thorough and catch corner cases and whatnot... For reference, here's how ...


1

For the time being, as everything on Stack Auth is "query when needed (which is rarely), cache for a day", the inclusion of rate limit headers is kind of pointless. Basically, if you ever need to check that you aren't hitting your quota... you're probably doing something wrong. There are naturally exceptions, but still in 99% of all cases the headers are ...


1

Pagination on /sites is solely so [app]s don't have to pull down any unknown, large, and constantly growing chunk of a data in a single request. It is expected that every consumer would grab all sites in a series of sequential (or concurrent, if they're comfortable with that) requests for each page.



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