I’m about to code up an New Relic API client in yet another language. This would be easier if there was a machine readable declaration for the API. This is the kind of thing some people do with Swagger (see swagger.io). Suggestions? Thanks!
I will pass this suggestion on to our Product Managers for their consideration.
Do you have any details about what interests you in using Swagger to create another interface in place of our current API? We would like to ensure that we are addressing the problem you want to solve. A use case or scenario of your intended use would be good supporting information for a Feature Request.
I think that answers my question. I.e.: No. New Relic does not provide a machine readable declaration for the API.
That is correct, at this time. I’ve sent your request along to the PMs.
Hi @Limey! I have a request similar to Ben’s, and I would be happy to provide supporting information.
My use case is that I’d like to import New Relic metrics into Sensu. The existing Sensu plugin is pretty awful and also doesn’t talk to the v2 API. I also notice that New Relic doesn’t seem to have updated the existing Ruby client for API v2, so I’m left with implementing a client for API v2 by myself.
I could certainly slog my way through the API documentation and implement each method by hand; there are some libraries that make it easier to build RESTful API clients in Ruby. However, if New Relic published a Swagger/OpenAPI specification of your API, then my work would consist mostly of feeding that specification into Swagger Codegen.
Thanks for supplying the justification and background. I’ve passed this along to our project managers as a Feature Request. They read them all. Can’t promise any immediate response, but this type of input helps them define what gets implemented in the future.
Regarding the existing Ruby gem, it is strictly for API V1. There has been no work on that and there will not be in the future, hence, the deprecation statement.
The Swagger Resource Declaration would seem to be a good way forward. We’ll see what happens.
Has there been any progress in providing a swagger/openapi file and/or to provide a proper integration API in Go, Python or any other language?
GoLang: (almost no update in 3 years)
Python: (no update in 3 years)
Hey @tblanchard - On our side we have not got an update on a Swagger implementation for our API. I can definitely get your +1 added for a better API implementation for machine readable API declarations. As per the original post here.
Though, the repos you link to our not made by, or supported by New Relic. It may be worth contacting their developers for info on how up to date they are, and any questions you may have on them.
I see that you’re now using a Swagger spec to document your API:
Is there any way I could get a rendered copy (i.e. flattened into a single file) to build myself a ruby client?
Hey @ikatz - I’m not 100% sure on what we can provide RE: rendered copy of the API Swagger definitions.
I will reach out to the appropriate people internally to try find out though.
I was able to dowload the
definitions.json referenced above, and with about a day of wrangling various tools (jq, the online Swagger editor, api-spec-converter, and swagger-codegen) was able to produce a Swagger-2.0-format version of your API. I am asking our legal team whether I can share it here.
I must stress how vital to NewRelic’s interests it would be to create and maintain a Swagger spec. Think of it this way: for the same effort you already put into documenting your API, your customers will be able to effortlessly create their own client in any of these languages (using a popular open-source tool):
Given that someone at your company is already using Swagger to document the API (https://rpm.newrelic.com/api/explore), this seems like an easy win. Is there a downside to being able to tell your customers (or prospective customers) that an API client is a 5-minute job to generate (vs “here’s the documentation, have fun developing and testing your own client from scratch”)?
Hey @ikatz - My colleague Alexander reached out to say that you are also in a support ticket with him. He’s in direct contact with the folks responsible for the API. So he’s in a better position to chat to about this. Let us know how that goes for you.
That is true, I opened the support ticket because the first API method I tried turned out to have been incorrectly documented. Hopefully we will kill 2 birds with 1 stone by fixing the content and spec format at the same time.
Hopefully! Let us know how it goes
It’s going poorly. I offered to simply hand over the Swagger 2.0 spec that I’ve been working on, so that it could be hosted on NewRelic’s GitHub account. This is what I got back:
it is not possible for us to release any internal source code to be public facing
What I’m talking about isn’t source code, and it’s already public-facing, which is how I got it in the first place… I assume something is getting lost in translation by not talking to the engineering team directly.
Can we all agree that New Relic is already using Swagger?
Hey @ikatz - Sorry that ticket isn’t going how you expected. You’re right, for parts of the API we definitely are using Swagger.
I’ll update your support ticket to see if we can get any more progress on this.
Thanks much! I’ve made a bunch of edits to the spec to match the behavior of the API, and my generated ruby client seems to work fairly well.
I should hear from our legal team this week about whether I can share the spec with everyone.
Awesome! Thanks for the work you’ve done on this
Hi @ikatz, I wanted to touch base with you and follow up on your need for a public Swagger API spec. Currently, we don’t have a public Swagger spec, but we have added a feature request, and I’ll be advocating with the right team to get this prioritized in our pipeline.
As well as the components it refers to, e.g.:
This is the Swagger spec that you use to produce the content on your API explorer page.
So when you say:
Currently, we don’t have a public Swagger spec
Are we in disagreement that you have (& actively use) a Swagger spec, or that your spec is public?