Skip to main content
Stack Apps

Return to Answer

replaced http://stackapps.com/ with https://stackapps.com/
Source Link
Community Bot
Community Bot
  • 1

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.discovering what versions of the API are available.

The tricky part is that the methods would not really fit well on the API for any of the real "content" sites, but instead would be a better fit for a special StackExchange API or a StackApps API. Any /Sites or /Versions methods could then be separated from the general API methods that are accessible from the content sites APIs.

In the future there could be other app-specific methods that are added such as key management or retrieving stats for your application (unique IPs, request count, etc). These all should be grouped in one place, which doesn't really have a home right now.

I think the best thing to do right now is to setup your App to bind to a hard coded JSON object that you create so that you are ready once such a method is available. Also some of the API Library and WrappersAPI Library and Wrappers already try and help manage the available sites to query, currently using hard coded enumerators but eventual could bind to an API method.

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 really fit well on the API for any of the real "content" sites, but instead would be a better fit for a special StackExchange API or a StackApps API. Any /Sites or /Versions methods could then be separated from the general API methods that are accessible from the content sites APIs.

In the future there could be other app-specific methods that are added such as key management or retrieving stats for your application (unique IPs, request count, etc). These all should be grouped in one place, which doesn't really have a home right now.

I think the best thing to do right now is to setup your App to bind to a hard coded JSON object that you create so that you are ready once such a method is available. Also some of the API Library and Wrappers already try and help manage the available sites to query, currently using hard coded enumerators but eventual could bind to an API method.

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 really fit well on the API for any of the real "content" sites, but instead would be a better fit for a special StackExchange API or a StackApps API. Any /Sites or /Versions methods could then be separated from the general API methods that are accessible from the content sites APIs.

In the future there could be other app-specific methods that are added such as key management or retrieving stats for your application (unique IPs, request count, etc). These all should be grouped in one place, which doesn't really have a home right now.

I think the best thing to do right now is to setup your App to bind to a hard coded JSON object that you create so that you are ready once such a method is available. Also some of the API Library and Wrappers already try and help manage the available sites to query, currently using hard coded enumerators but eventual could bind to an API method.

Source Link
Greg Bray
Greg Bray
  • 175
  • 1
  • 3
  • 8

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 really fit well on the API for any of the real "content" sites, but instead would be a better fit for a special StackExchange API or a StackApps API. Any /Sites or /Versions methods could then be separated from the general API methods that are accessible from the content sites APIs.

In the future there could be other app-specific methods that are added such as key management or retrieving stats for your application (unique IPs, request count, etc). These all should be grouped in one place, which doesn't really have a home right now.

I think the best thing to do right now is to setup your App to bind to a hard coded JSON object that you create so that you are ready once such a method is available. Also some of the API Library and Wrappers already try and help manage the available sites to query, currently using hard coded enumerators but eventual could bind to an API method.