Registration 2.1 - Delete "operation" parameter
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.
Comments (4)
-
Account Deleted -
reporter 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.
-
reporter -
assigned issue to
The operation parameter was only needed for rotate_secret, so we will delete this.
We will also require client_id on update operations.
-
assigned issue to
-
reporter - changed status to resolved
Fixed
#746- Deleted the "operation" parameter. Fixed#745- Deleted the "rotate_secret" operation.→ <<cset 9f23a7bbbeff>>
- Log in to comment
I don't like the side-effectful switch of using client_id, as an alternative I would propose one of the following: