Add HTTP endpoints for the handshake and channel registrations

[ghost]

For proprietary pingers that can bypass the WebSocket (i.e., GCM and APNS), it doesn't make much sense for the client to initiate a WebSocket connection, send a handshake with the connect field, and then disconnect. What if we exposed HTTP endpoints for these, too?

> PUT /devices/ddae09b80fde42549b85b10e36ecf876 HTTP/1.1
> Host: updates.push.services.mozilla.com

{
    "messageType": "hello",
    "uaid": "ddae09b80fde42549b85b10e36ecf876",
    "channelIDs": [],
    "connect": {
        "regid": "{registrationId}"
    }
}

< HTTP/1.1 200 OK
< Date: Wed, 14 Jan 2015 18:31:49 GMT
< Content-Type: application/json

{
    "messageType": "hello",
    "uaid": "ddae09b80fde42549b85b10e36ecf876",
    "status": 200
}

And for registering channels:

> PUT /devices/ddae09b80fde42549b85b10e36ecf876/channels/7c5f7018d92b419dac22e4f80db8c69f HTTP/1.1
> Host: updates.push.services.mozilla.com
> Content-Type: application/json

{
    "messageType": "register",
    "channelID": "7c5f7018d92b419dac22e4f80db8c69f"
}

< HTTP/1.1 200 OK
< Date: Wed, 14 Jan 2015 18:31:49 GMT
< Content-Type: application/json

{
    "messageType": "register",
    "uaid": "ddae09b80fde42549b85b10e36ecf876",
    "status": 200,
    "channelID": "7c5f7018d92b419dac22e4f80db8c69f",
    "pushEndpoint": "https://updates.push.services.mozilla.com/update/{endpointKey}"
}

(There's no need to include the device and channel IDs in the body if they're already in the URI; I just used the same hello and register message formats for clarity).

[ghost]

If we used Link headers instead of JSON entity bodies, we'd end up with Web Push's "registration" and "subscription" flows. :smile_cat:

[jrconlin]

I'd argue a bit differently. I agree that the websocket requirement is a pain, but I'd also argue that for this, we don't need the separate "Hello". For many cases, the UAID is either known or is not specified which means that it's created new. I could also argue that in many cases applications have one channel, but that's a separate concern.

I think having a single "registration" point where you pass the UAID (either known or blank) and ChannelID and get back a response containing UAID & EndPoint is sufficient in most cases. z

I suppose that if we really wanted, we could make the same registration endpoint return just a new UAID if the user doesn't specify a CHID.

Granted, tying the UAID to the user for any other reason becomes more of a concern, but that's not really our concern either.

[ghost]

I think having a single "registration" point where you pass the UAID (either known or blank) and ChannelID and get back a response containing UAID & EndPoint is sufficient in most cases.

Excellent. Correlating IDs to users does become more challenging, but we could argue this is a proprietary mechanism, anyway—"use at your own risk."