cloudant_rp.mdown

Windows Azure "ResourceProvider" Design

Windows requires us to have a ResourceProvider (RP) that responds to HTTP requests, in order to mediate requests around Subscriptions and Resources.

Subscriptions

Subscriptions are roughly analagous to a Cloudant account. The RP need only respond to POST requests at https://<base_uri>/subscriptions/<subscription_id>/Events. The request body of requests against this URL are detailed here. In essence, the nature of the request body will prompt the RP to handle one of four event types:

• Registered: Create an account.
• Disabled: Disable access to the account, but do not delete its data.
• Enabled: Restore access to the account.
• Deleted: Delete an account (though Azure recommends retaining data for 90 days, in case the account is reactivated).

Regardless of the event type, the RP should respond 200 or 201 for success. If the RP responds with anything besides 200 or 201, Azure will try the same request again until the RP responds with 200 or 201.

Resource

Resources correspond to Cloudant databases. The RP must handle CRUD operations for resources as follows:

• GET: Return information about the requested database.
• PUT: Create a new database.
• POST: Upgrade the specified database to a new tier of service.
• DELETE: Delete the database.

N.B. You read that right: PUT creates, POST updates. More curiously, the Resource API page says no route uses POST, but the Upgrade Resource page indicates it uses a POST. (╯°□°)╯︵ ┻━┻

Since Resources seem analogous to databases, it is unclear whether we need to provide CRUD operations on them through the RP, since the authentication credentials provided during account creation are sufficient to interact with databases and documents. I've sent an email to our technical contact at Microsoft (CC'd Sam) to clarify.

How are authz and authn supposed to be handeled for subscriptions?

We can't let just anyone call that end point.

Ahh-client side certs - https://github.com/WindowsAzure/azure-resource-provider-sdk/blob/master/docs/api-overview.md#authentication

Wahwah:

"Requests will be made in XML. JSON is not currently supported, but is being considered for future revs of the API."

The XML Microsoft passes converts to JSON without any fuss, at least currently. Their test repos currently contain an XML->JSON parser which passes their test suite, so that's pleasant.