denominator
denominator copied to clipboard
Netflix
Migrate to UltraDNS new REST Api
@jonbodner can you put more context here? Ex. links to docs, base url, if a different auth scheme is needed (or accounts), if there's a test endpoint, any functionality gaps with what we're using, any stability notes?
Functionality-wise, the REST API should be a super-set of the SOAP API at this point.
You can find a quick start guide at https://restapi.ultradns.com/v1/docs . The full documentation is in PDF form on the Java UI (need to get it on the REST API site, too).
Authentication is with a subset of OAuth 2.0 (https://tools.ietf.org/html/rfc6749#section-4.3). We expect that the primary usage of the REST API is via scripts and other trusted applications, so we haven't implemented full-blown OAuth.
The API tries to be a pretty standard REST API; POST to create, GET to get, PUT/PATCH to update, DELETE to delete. PATCH can be performed with either the same data structure returned via GET or with JSON-PATCH (you have to set the content type so we know which one is being sent).
/zones/{zoneName} is for zone metadata access
/zones/{zoneName}/rrsets/{type}/{ownerName} is for resource record set access. Everything is at the resource record set level; you don't address individual resource records.
(owner name is the technical name for a domain that has resource records defined at it)
Pools are at the same endpoints as standard resource records. The difference is that the content has a "profile" section that contains the pool-specific information. Converting from one pool type to another (or between pools and standard rrsets) is a matter of using PUT/PATCH to change/remove the profile section.
Probes for sitebacker/traffic controller are at:
/zones/{zoneName}/rrsets/A/{ownerName}/probes/{guid}
In general, guids are hidden, but some things (like probes) don't have names associated with them that work well in URLs, so we fall back to GUIDs.
Multiple operations can be grouped together into a single batch POST; if any fail, all are rolled back.
Stability seems to be fine.
Sample clients for the REST API can be found on github at: https://github.com/ultradns/python_rest_api_client https://github.com/ultradns/ultradns-sdk-ruby https://github.com/ultradns/ruby_rest_api_client https://github.com/ultradns/js_rest_api_client https://github.com/ultradns/perl_rest_api_client https://github.com/ultradns/java_rest_api_client
Coelacanth, the JSON specification for zones that forms the basis for the REST API's data format, is documented at: https://github.com/ultradns/Coelacanth
If you need a copy of the PDF, let me know and I can pass it along.
ok, so one decision we have to make is about PATCH (and the terrible UrlConnection thing). Choices I know of are don't use it (ex. use POST instead), require a client be passed in that supports PATCH (ex. OkHttpClient), or we use the gnarly debty work-around to hack various JRE's to support PATCH.
Thoughts? cc @jdamick
I just checked and _method=PATCH as a query parameter does work.
curl -X POST -H "Authorization: Bearer 849f6506e3b2434f886e71d146d604da" -H "Content-Type: application/json" -H "Accept: application/json" -d '{ "ttl":400 }' http://localhost:8080/v1/zones/testing.invalid./rrsets/A/foo?_method=PATCH
+1, no awesome patching required.
On Thu, Mar 12, 2015 at 1:26 PM, Jon Bodner [email protected] wrote:
I just checked and _method=PATCH as a query parameter does work.
curl -X POST -H "Authorization: Bearer 849f6506e3b2434f886e71d146d604da" -H "Content-Type: application/json" -H "Accept: application/json" -d '{ "ttl":400 }' http://localhost:8080/v1/zones/testing.invalid./rrsets/A/foo?_method=PATCH
— Reply to this email directly or view it on GitHub https://github.com/Netflix/denominator/issues/289#issuecomment-78537307.
Hi,
any news here? Neustar finally announced sundown of the SOAP API for March 31th, 2017.
Regards, Jan
Jeff might have started something. I've opened this issue on the future of denominator as you've raised a valid concern https://github.com/Netflix/denominator/issues/374
