![]() ![]() Deprecation is how Tech Co broadcasts an intent to delete a route. ![]() This is slightly different than a warning: 199 header, which you will receive if an endpoint was updated and there is now a newer version of it available. When an endpoint is deprecated, a line appears through it on the swagger UI, and it begins returning the "warning: 299" header. Additionally, we will be updating a stickied thread in the EVE Technology Lab subforum as changes happen.Īdditionally, endpoints may be deprecated. In that case, prudent developers may want to create unit tests (watch for the "warning: 199" headers) to notify them when endpoints are moved to legacy. If you want to avoid the return schema of your request suddenly changing, you can use the versioned alternate route. After changes are made the previous /latest/ will be available as /legacy/, until the next version bump. dev/ can change at any point, changes to /latest/ will be announced. Alternate routes are mentioned in the route description (until something better comes along in the standards?). But each route is also given a numbered path, starting with /v1/. With ESI, you always (and only) get three complete APIs, /dev/, /latest/ and /legacy/. This is obviously a little less than ideal, considering there could be hundreds of other unchanged routes. With a traditional API, the entire APIs basePath would have to be bumped. This allows us to make much faster changes and avoid the awkward situation of global API versioning.Īs an example, let's say you have a route /v1/hello//, and you want to change the path parameter to accepting an integer instead. Instead, ESI versions each route individually. SSO is not multi-tenant though, so you will need to create app keys on each SSO backend you intend to use.ĮSI itself will have an API version (as defined in the spec), that version number however, is mostly irrelevant to API consumers (it's the version of ESI-lib). Mouse hovering over this icon will tell you what scope the endpoint requires.ĮSI will handle redirecting your authentication header to the correct SSO for verification (depending on the datasource query string argument). If an ESI endpoint requires authentication, you will see a red exclamation mark on the route description in the swagger UI. There are new scopes which ESI uses, you can make new developer keys (or alter your existing) to make use of the new scopes. With esi-dev or esi-test and a bit of configuration (which will be replaced with tooling), EVE developers can actually query their local development server through ESI.Īuth is still handled by SSO. You will see this in the ESI UI as a select menu in the header/nav bar, and in the datasource enum in the spec itself.Īs a (potentially) interesting side-note here, there are actually three ESI environments running, an esi-dev, esi-test, and the production esi. As such, if ESI and the cluster agree on configuration, you can change the datasource query parameter on any route (including //swagger.json) to the server name of your choice. Most of this is transparent to the front-end, but may be of interest to some capsuleers regardless.ĮSI was designed to be a single interface to all information EVE related. This blog will dive a little deeper into the design and technical specifics of ESI, going to get into the base design of ESI to explain a few basic principles of what's going on behind the scenes. If you don't know what this is, you should go here to read the blog Introducing ESI - A new API for EVE Online. The EVE Swagger Interface is a new framework developed by Team Tech Co to underpin the new ESI API. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |