Hacker News Reader

Hacker News

Comment by Traubenfuchs | Hacker News Reader

Full thread

Traubenfuchs

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.)

View on HN

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

You might not want a dedicated „Signup“ entity in your model and db.

you would POST to /users

what's the confusion? you're creating a new user entity in the users collection.

...so? Don't have one.

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. Its approach would be to add information about signup in a request to the post to /users: https://google.aip.dev/133. More or less it describes a way to be RESTful with HTTP/1.1+JSON or gRPC.

> 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 .

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.

It's not ambiguous that api/users/signup refers to a resource. One of the constraints of REST is that endpoints refer to resources.

Reply on news.ycombinator.com