Tag Info

Hot answers tagged

17

The gravatar url can be calculated from the email hash. string gravatarUrl = "http://www.gravatar.com/avatar/" + emailHash + "?d=identicon&r=PG"; More gravatar info.


14

It's explained here Version 1 is read only. Coming up with a solid API is hard enough without adding writing and authentication to the mix. For the initial release, it’s a read-only API. We’ll take on the much more challenging problem of writing (and authentication) in v2.


10

There wouldn't be a lot of code re-use between the SE API (.NET), OSQA (Python) and Shapado (Rails). If others want to, they can implement a compatible API without any of the server-side code. In fact, that's one of the biggest selling points of this type of API, it uses standards like HTTP and JSON that you can produce with any web framework. With a ...


9

I agree that there needs to be a way to discover API endpoints. Especially with the brave new world of SE 2.0 potentially leading to an ever increasing number of API-ified sites out there. However, there isn't a good place to shove this functionality just yet. Currently, we only have two places it could go: ...


8

No we don't. It is an app. Simplicity is key to keep clutter at a minimum. The current two categorizations are perfect: An app is something you make that utilizes the API to do something. A library is something that provides an abstraction between an app and the API. No need to invent a bunch of categorizations that aren't necessary.


8

This is a tricky one, and I can't really say how it will be solved in the future but we'll have to figure out something. The inability to render questions is kind of a major deficiency (if one that didn't exist until well after 1.0 was frozen). This has been added in 1.1. /1.1/sites reports markdown_extensions with values Prettify, MathJax, and jTab as ...


7

I guarantee that if we did this, a large chunk of the developed apps would rely on /latest and break horrendously every time we rev'ed the API. The end user experience would be bad, developers would be frustrated (as their code literally just stopped working one afternoon), and we'd have to deal with a bunch of erroneous bug reports ("/some/method stopped ...


6

Totally agree. You need a way to "deactivate" a key. For sure.


6

This is definitely private and should not be exposed by a read-only API that does not authenticate for that user.


6

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

They have been very clear that version 1 of the API will be read only and they will be revisiting the POST type features (like adding new questions and answers) for the next version of the API. You can post and vote for the features you would like to see in the next version here. You can also view any feature requests which have been deferred to some future ...


6

http://stackauth.com/1.0/sites will get you information about all the sites.


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 ...


6

For /sites (and only it) I have removed the pagesize constraint. I believe in this case it makes sense, since applications are expected to query all of that data and cache it for long periods of time. The constraint remains elsewhere, as it's very important for performance reasons.


6

I don't see any particular reason not to add it, but there are some workarounds you can use in the meantime: Build a cache of all site information with the site URL as the key, and then look up the api_site_parameter value (and associated information) that way. or Use the fact that the domain name can be passed in as the value for site, and clean up ...


5

This is important if you want to be able to build an app that supports all available sites. Right now there are only a few, but eventually the list will grow and simply adding entries by hand will become too difficult. There also was a similar request for discovering what versions of the API are available. The tricky part is that the methods would not ...


5

Currently there is only one version alive at a time (0.8). While in beta, I'm guessing this will be the norm. Once out of beta, there will probably be an upgrade period for minor versions ("1.1 is released! Update your 1.0 apps!"). However, for major versions there will be two api's running at the same time (1.0 and 2.0). From the original API ...


5

This would be a good idea, as it would immediately clue developers into the resources that are here specifically to make the API easier to use.


5

While this would indeed be ideal for planned outages, your code and/or libraries & dependencies should be able to handle this elegantly, lest you get bitten by the unplanned outages.


5

It is supposed to include answers (probably first page only), and documented (look for "answers" in return json), but there was a bug, and it has been fixed recently. But yes, I also think answer=true option would be nice.


5

Actually, I think I figured out a way to do this. If you specify the following: /users?filter=john&sort=name&min=john&max=JOHN That is, sort by name with "min" and "max" both set to "john" then it returns only those people whose name is exactly John. I wonder whether this efficient for the backend to process? It seems to respond pretty ...


5

pagesize=0 is now permitted. You can use this to get total on all the methods that support paging, generally very quickly.


5

No. Its far too late in the v1 game to add something this complex. Note that the current policy is that you shouldn't be polling faster than once a minute, not two minutes.


5

Read the blog entry about it http://blog.stackoverflow.com/2010/01/what-would-a-stack-overflow-api-look-like/


5

The icon_url images returned by StackAuth (and /stats) should all now have transparent backgrounds.


5

You know where it would really be noticed? That little announcement strip at the top of the page under the logo. Maybe: Writing an app? Check out the list of libraries.


5

I believe that's a correct approach. There's a way to optimize it saving one request but it's a little bit unsafe for this bug: call /questions/{id}; If you get a result with a title parameter it's a question If you get a result without a title parameter it's an answer, thus you should call /answers/{id} for the title EDIT: I've just realized that ...


5

Whelp, that was an oversight. accept_rate should now be returned on both user and shallow_user. Note that when insufficient data is available to calculate an accept rate, we don't return anything at all. The exact rules for calculating accept rate are subject to change, but currently documented here. The API returned accept rate should always match the ...


5

API V2 did this, we send down: Access-Control-Allow-Credentials: false Access-Control-Allow-Methods: GET, POST Access-Control-Allow-Origin: * With every response.


4

I totally agree: Discussion: dialog revolving around a topic Support: a request for assistance or clarification discussion != support



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