Common API requests (CSM)
All this data is potentially out of date, and should be taken with a truckload of salt
The API has become an important part of the Eve experience, with countless pilots using programs like EFT, Evemon and EveHQ. However, the API is far from perfect and there are many requests from the API development community. This document outlines the requests. Items in green are most frequently requested/mentioned.
- Little to no community interaction with regards to enhancements, fixes, or new features. Despite the low numbers of people in the API development community, the EVE population as a whole use API features, so good support of the API is good support for features that large numbers of people use. Right now things are great because there is a dedicated team working on the API, but when this team moves on, there should still be somebody around to work on the API.
- EVE Gate provides some information not available via the API, and it is not allowed to scrape EVE Gate. This is frustrating for those people who do not want to break the rules.
- CCP needs to provide better support for fixing bugs and quirks that are reported by the players about the API.
- The API was originally introduced partly as a way for people to give out verifiable account information without giving up sensitive information such as username and password. As the amount of information available via the API grows, security issues become more and more of a concern due to both theft and misuse of API keys. Every new API call that is implemented ought to have this possibility in mind, to minimize misuse – in the sense that security should be considered, instead of limiting information.
- userID gives away far too much information and must no longer be used
- Greater granularity in api permissions. There were different schemes proposed, but what all of them have in common is some sort of access control list controlled by the user/corp that can dictate what pages can be pulled by an api key. Allowing the creation of multiple API keys with different levels of permissions(instead of full VS limited) would also be useful as people give keys out to different places, for different reasons. Some sort of scheme like this can be used to augment or replace the full vs limited API key scheme we have now.
- HTTPS requests for api key calls, to prevent 'sniffing' api traffic to steal keys
- EVEmails via API raises privacy concerns
- Create an API for the API access log. It will allow automation of API intrusion checks and allow for greater security. Currently to check for security breach of your api, you need to log into the api site every week and remember which IP addresses ought to have access.
- Allow blacklists, or whitelists of IP addresses. If you give you key to a site, you're doing it with the understanding that no other site should have access.
- Give out information about concord sanctioned wars via api
- For every item that is shown through the API(alliance info, corp info, conquerable station, system status, indexes, sovereignty, character info, etc), give out all the information that is available via Show Info. But not he sorts of info that would require ingame intelligence gathering such as reinforcement timers. The eventual goal is to make everything that is available through Show Info, available through the API or the data dump.
- Starbase API- reveal the POS module setup, silo fill levels, gun ammo fill levels, starbase name. X/Y/Z coordinates for pos modules, or location of the moon they are anchored at.
- Some sort of api call that allows determining the difference between bpo and bpc. Also make the difference between bpo and bpc available on killmails.
- Oauth support for the api and eve gate
- Killmails API requires a full director api. killmails are not even secret information, but in order to pull them you must give access to a lot of secret information. The security requirement should be lower. Some sort of way to verify killmails without needing an API key would be good, and XYZ coordinates of the kill would aid in recreation of the battle.
- PI information- list of planets, list of structures on all planets, list of all silo structures and their contents
- For API pages that return large numbers of results, allowing us to pass parameters that limit the size of the returned data to only specific parts of the full document, would allow for less load on the servers. One example is the assets page, allow us to limit the request to only certain stations.
- Contracts API
- Jump Clone Information + implants
- Implant information, employment history, everything else that is missing between the API and ingame, on Character Sheet
- The idea of being able to send evemails via the API was brought up. I think that giving any sort of write access through the API is a big step and will need a lot of careful consideration, not the least of which will involve security. It will undoubtedly improve the user experience though so I will include this anyways.
- gzip/deflate encoding on the API responses
- Notification bodies
- One-time-use API keys to be used for character authentication and nothing else
- #eve-dev on irc.coldfront.net log at: http://pastebin.com/UAGC18As
- Pandemic Legion forums
- eve-dev API wishlist
- Feedback requests to many 3rd party API developers