3 ms·

REST(ful) API issues can all be resolved with one addition: Adding actions to it! POST api/registration / api/signup? All of this sucks. Posting or putting on

REST(ful) API issues can all be resolved with one addition: Adding actions to it! POST api/registration / api/signup? All of this sucks. Posting or putting on api/user? Also doesn‘t feel right. POST to api/user:signup Boom! Full REST for entities + actions with custom requests and responses for actions! How do I make a restful filter call? GET request params are not enough… You POST to api/user:search, boom! (I prefer to use the description RESTful API, instead of REST API -everyone fails to implement pure REST anyways, and it‘s unnecessarily limited.)

thaumasiotes 1y ago
What is the problem with posting to /user/signup that posting to /user:signup solves?
- Traubenfuchs 1y ago
  You might not want a dedicated „Signup“ entity in your model and db.
  - Tokumei-no-hito 1y ago
    you would POST to /users what's the confusion? you're creating a new user entity in the users collection.
  - thaumasiotes 1y ago
    ...so? Don't have one.
- no_circuit 1y ago
  The system won't be able remember why the user was created unless the content of the post includes data saying it was a signup. That's important for any type of reporting like telemetry and billing. So then one gets to bike-shed if "signup" it is in the request path, query parameters, or the body. Or that since the user resource doesn't exist yet perhaps one can't call a method on it, so it really should be /users:signup (on the users collection, like /users:add). Provided one isn't opposed to adopting what was bike-shedded elsewhere, there is a fairly well specified way of doing something RESTful, here is a link to its custom methods page: https://google.aip.dev/136 https://google.aip.dev/136. Its approach would be to add information about signup in a request to the post to /users: https://google.aip.dev/133 https://google.aip.dev/133. More or less it describes a way to be RESTful with HTTP/1.1+JSON or gRPC.
  - thaumasiotes 1y ago
    > So then one gets to bike-shed if "signup" it is in the request path, query parameters, or the body. But that's not a difference between /user/signup and /user:signup .
    - no_circuit 1y ago
      That's correct, the example you are giving represents bike-shedding among request path variations. I assumed most readers of my comment would get that the idea that /users/signup is ambiguous whether or not that is supposed to be another resource, while /users:signup is less so.
      - rendall 1y ago
        It's not ambiguous that api/users/signup refers to a resource. One of the constraints of REST is that endpoints refer to resources.

thaumasiotes 1y ago

What is the problem with posting to /user/signup that posting to /user:signup solves?

Traubenfuchs 1y ago
You might not want a dedicated „Signup“ entity in your model and db.
- Tokumei-no-hito 1y ago
  you would POST to /users what's the confusion? you're creating a new user entity in the users collection.
- thaumasiotes 1y ago
  ...so? Don't have one.
no_circuit 1y ago
The system won't be able remember why the user was created unless the content of the post includes data saying it was a signup. That's important for any type of reporting like telemetry and billing. So then one gets to bike-shed if "signup" it is in the request path, query parameters, or the body. Or that since the user resource doesn't exist yet perhaps one can't call a method on it, so it really should be /users:signup (on the users collection, like /users:add). Provided one isn't opposed to adopting what was bike-shedded elsewhere, there is a fairly well specified way of doing something RESTful, here is a link to its custom methods page: https://google.aip.dev/136 https://google.aip.dev/136. Its approach would be to add information about signup in a request to the post to /users: https://google.aip.dev/133 https://google.aip.dev/133. More or less it describes a way to be RESTful with HTTP/1.1+JSON or gRPC.
- thaumasiotes 1y ago
  > So then one gets to bike-shed if "signup" it is in the request path, query parameters, or the body. But that's not a difference between /user/signup and /user:signup .
  - no_circuit 1y ago
    That's correct, the example you are giving represents bike-shedding among request path variations. I assumed most readers of my comment would get that the idea that /users/signup is ambiguous whether or not that is supposed to be another resource, while /users:signup is less so.
    - rendall 1y ago
      It's not ambiguous that api/users/signup refers to a resource. One of the constraints of REST is that endpoints refer to resources.