One verb per URL (and actions described in the URL along the verb) makes a very weird REST API.
@aeveltstra Internal service, not sure if I can openly share it.
@aeveltstra Also, no `POST /resource` 'cause what it would do is done by `POST /resource-add`.
@juliobiason Yes, I agree that's a weird-looking API design. Did the designer forget that HTTP verbs exist, when they thought up the endpoints?
@aeveltstra It's one of the new guys, and I'm not sure if it is just inexperience or there is something in the framework that makes easier to have this kind of URLs.
That's why I'm going to talk to him, so I can understand why he came up with those URLs.
@juliobiason @aeveltstra don't see that this is a problem as long as the resources themselves have self/edit links or the equivalent. Making people worry about the format of URLs client side is nasty anyway, unless it's in a well-defined way like URL templates. Atom will return!
(Well, actually I work with Atom daily so I'm happy already.)
@bkhl @juliobiason A web service API design in which each HTTP verb is mapped to a different endpoint URL is quite different from what I'm used to using. I have the expectation that an endpoint can do CRUD, or not. Not that parts of the CRUD require other URLs. But: at the same time I don't really care as long as it's documented well. I just configure whatever endpoint.
@aeveltstra @juliobiason there are plenty of Atom based APIs where there is no particular _need_ for those URLs to be the same, as they all have different relations to the main entity. The presence of those links are what tells you the HTTP verbs are available. That is, you can only expect to update or delete a thing if you have an rel"="edit" or rel="delete" rel link to it, which might or might not have the same href (though in practice they usually have).
functional.cafe is an instance for people interested in functional programming and languages.