Registration 2.1 - Delete "operation" parameter

[Michael Jones]

After deleting the rotate_secret operation, the remaining operations would be client_register and client_update. These take essentially the same parameters, except that the client_update operation would contain a client_id. The presence of the client_id parameter would be used to distinguish between these closely-related operations.

P.S. With these changes, “client delete” operation could be performed with an HTTP DELETE method and a “get client status” operation could be performed with a HTTP GET method. I’m not advocating these operations, because I don’t think they’re needed in a minimal spec, but I did want to put out that the simplifications proposed above would align with the possibility of adding them later, should the working group decide that it’s important to do so.

[Former user]

I don't like the side-effectful switch of using client_id, as an alternative I would propose one of the following:

• define two separate logical endpoints, one for new registration and one for updates
• use different HTTP verbs: POST for "create" and PUT (with client_id in body) for update

[Michael Jones]

I completely disagree with the multiple endpoints approach. The Web Services experience with having an endpoint per operation was atrocious. It was part of the weight of complexity that made the whole thing unapproachble/unwieldly/unimplemented.

As for "PUT", in many cases clients will only have access to two verbs - "GET" and "POST". We should limit ourselves to using those, for implementability/deployability reasons.

[Michael Jones]

The operation parameter was only needed for rotate_secret, so we will delete this.

We will also require client_id on update operations.

[Michael Jones]

Fixed #746 - Deleted the "operation" parameter. Fixed #745 - Deleted the "rotate_secret" operation.

→ <<cset 9f23a7bbbeff>>