Migrate to UltraDNS new REST Api

[codefromthecrypt]

This tracks moving from UltraDNS' SOAP Api to the new REST one.

[jonbodner]

Let me know if you need any help with the transition.

[codefromthecrypt]

@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?

[jonbodner]

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.

[codefromthecrypt]

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

[jonbodner]

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

[jdamick]

+1, no awesome patching required.

On Thu, Mar 12, 2015 at 1:26 PM, Jon Bodner notifications@github.com
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
#289 (comment).

[roehrijn]

Hi,

any news here? Neustar finally announced sundown of the SOAP API for March 31th, 2017.

Regards, Jan

[codefromthecrypt]

Jeff might have started something. I've opened this issue on the future of denominator as you've raised a valid concern #374

[bhagavan-ankam]

Do we have api's to add and delete the CName