I've implemented several REST API's with nearly POST only. And they are damn clean, you can easily generate SDK e.g. from type-safe C# to type-safe TypeScript and you can read it like you would a normal API.
My goal with REST API's is clean SDK, e.g.
In web server I have Namespace.SomeController.Save it will be: /Namespace/Some/Save/ and it will generate Namespace.Some.Save() function to TypeScript. Highly recommended.
You don't need to be verb purist (for some reasons you already covered), but key to me is to have unique url for all endpoints to keep it clean and easily generateable.
That isn't a REST API, by any measure of the word. It's a case of en.wikipedia.org/wiki/Remote_proce.... That's not to say that that's inherently bad (far from it), but to call it 'REST' it needs to at least have a reasonable amount of overlap with what is generally considered 'REST'.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Very nicely done.
I've implemented several REST API's with nearly POST only. And they are damn clean, you can easily generate SDK e.g. from type-safe C# to type-safe TypeScript and you can read it like you would a normal API.
My goal with REST API's is clean SDK, e.g.
In web server I have Namespace.SomeController.Save it will be: /Namespace/Some/Save/ and it will generate Namespace.Some.Save() function to TypeScript. Highly recommended.
You don't need to be verb purist (for some reasons you already covered), but key to me is to have unique url for all endpoints to keep it clean and easily generateable.
That isn't a REST API, by any measure of the word. It's a case of en.wikipedia.org/wiki/Remote_proce.... That's not to say that that's inherently bad (far from it), but to call it 'REST' it needs to at least have a reasonable amount of overlap with what is generally considered 'REST'.