4 ms·

Right. So you bought into it, sounds like. Almost every other software developer did too. They all think they had an epiphany. They didn't. As for me, for 30 y

Right. So you bought into it, sounds like. Almost every other software developer did too. They all think they had an epiphany. They didn't. As for me, for 30 years I've known software function calls are inherently verbs and I'm not gonna let a trending "meme" (like REST) convince me otherwise. haha. I mean it's not so much the "nouning" of verbs that's the problem, but it's the loss of the ability to use verbs that I find so appalling. I mean if I need to run some reports it had better be called "runReports()" not some janky update of a state of some 'report' object to change it to 'running' state. So silly. REST is so jank. I mean what if "runReports()" needs to start N number of independent reports and return the status of startup of each one. With REST you always end up fighting things like that which are totally trivially easy without the REST nonsense.

mattmcknight 6y ago
I didn't really have an epiphany or buy in, I just figured out a way to think about it so I wasn't worrying about verbs all of the time. Purity in all things is a problem, REST included. One thing that kind of gets you is that HTTP itself is not the best transport for all of these things. If we are talking about something that has to run over HTTP, we might do something like create a run of reports (maybe a POST to reports/run). That could return a list of report_ids that were created and their associated status, with an run_id associated with the collect run. There's no fighting! However, if you want that data streaming back to you, this is where you might think you want something more like WebSockets. For some use cases, this can be more efficient than having the client polling to see if the result of a long running process is ready. It all depends. Anyway, not advocating for anything here, just pointing out that I had the same worry about supporting a rich vocabulary of verbs, but then kind of realized it didn't matter because all verbs you want can be nouns. If you are using HTTP though, the REST verbs match up pretty nicely with how the protocol works, so it avoids inventing another abstraction to sit on top of it.
- WClayFerguson 6y ago
  You seem to realize that an RPC API design is totally separate concern from HTTP, and I agree with most of what you're saying, but then in your last sentence you say "REST verbs match up nicely" and can simplify your API. Respectfully, no it can't. REST doesn't remove abstraction layers, it creates abstraction layers. Whether you do REST or not you will have an interface between client and server, which has to be documented and have a well defined set of nouns and verbs, period. Can't be avoided. Removing my choice of verbs does NOT simplify things. If my API only needs CRUD verbs that's what I'll use. No problem. But forcing me into those 4 verbs, only, ever, and always (as pure REST does) is not a help, it's a hindrance.
  - mattmcknight 6y ago
    By "REST verbs match up nicely", I meant REST verbs match up nicely with HTTP methods...(there are currently about 9 HTTP methods?). That's why it's not an additional abstraction, a POST is a POST. Compared to SOAP, which is where I came to it, it's tightly aligned with the transport. (People used to advocate for SOAP saying you could use it over SMTP...). If you are going to do a non-HTTP API, REST doesn't make a lot of sense. Anyway, I was still annoyed by the limited verbs 10 years ago after using REST for five years at that point. I even blogged about it, as I started doing HATEOAS about that time, so I really feel your annoyance. I've just discovered over time that the verb/noun thing is just stylistic, not an actual technical concern. All of your verbs can be nouns.
    - WClayFerguson 6y ago
      I've also done plenty of SOAP back in the day. I independently invented the equivalent of SOAP in an API back in 1998 where my RPC API used only one method, which was basically a "call(command)" for sending XML data upstream and getting an XML response (C++ app). The request XML had the "name" of the "verb" as part of the request. Basically a "command pattern". So what I do today is I use "REST APIs" (like in Java Spring, Axios/Ajax, etc.) but all my endpoints are named as "verbs" (not nouns), and the only HTTP verb I ever do is a "POST". So everything boils down to this: let myJsonReponse = api.doSomeVerb(myJsonRequest);
jayd16 6y ago
Creating nouns out of your RPC is actually powerful and transformative. Verbs are transitive but nouns can be queried, handled asynchronously etc. It feels like jumping through hoops but you end up with a more solid API for the web.
- WClayFerguson 6y ago
  I like code that's simple to understand like this: ``` let user = api.getUser(); user.setName("Clay"); api.saveUser(user); ``` That's just a basic RPC API. No one will ever convince me that turning all that into some kind of noun-based equivalent is better. The fact that a GET and a POST are HTTP verbs that match up to that is is meaningless to me because I could care less about the HTTP layer in my API design. APIs should be decoupled from all underlying architecture as much as possible. REST is about TIGHTLY COUPLING THEM as much as possible. Bad idea.
  - jayd16 6y ago
    > No one will ever convince me Well for anyone else listening, a RESTful design would help you know whether you're creating or updating a user. You would know if you're allowed to repeat the request without side effects. That's useful in a distributed api where half open requests are inevitable.
    - WClayFerguson 6y ago
      I think with functional programming developers are capable of knowing whether they're creating or updating a user. However with REST I can't "transmogrify" a user. Do you know what a "transmogrification" is? No you don't. Because REST doesn't do that. It's a domain specific verb I made up. To force REST to work you'd have to invent a new noun called "transmogrify state", even if no one would have ever conceived of that state in a functional programming design. Whenever you end up inventing new objects specifically to work around architectural limitations, that's not a simplification. :) Functional Programming works. Nothing invalidates verbs just because you're doing them over HTTP, for example. Your API design should have no clue if it's running over HTTP or something else.
tuesdayrain 6y ago
>I mean if I need to run some reports it had better be called "runReports()" not some janky update of a state of some 'report' object to change it to 'running' state. So silly. REST is so jank. I fail to see how that's janky, it sounds like a great abstraction. I would have a 'createReports()' method that returns an array of Report objects that all correspond to a record in a database. Easy to query for the state, id, or any other details I might need. Doesn't get any cleaner than that in my opinion.
- WClayFerguson 6y ago
  Yes, we agree. What I meant is I'd have a verb that creates and returns some kind of "ReportContext" object, which sends back an "id" which I can then query status of later, for example. But no REST. My point is that the entire endpoint would be mostly verbs (like runReports) and use only the HTTP POST to communicate. So I'm "ignoring" the fact that it's running over HTTP, I would ignore every "rule" of REST, because REST offers nothing but hurdles to jump over.

mattmcknight 6y ago

I didn't really have an epiphany or buy in, I just figured out a way to think about it so I wasn't worrying about verbs all of the time. Purity in all things is a problem, REST included. One thing that kind of gets you is that HTTP itself is not the best transport for all of these things. If we are talking about something that has to run over HTTP, we might do something like create a run of reports (maybe a POST to reports/run). That could return a list of report_ids that were created and their associated status, with an run_id associated with the collect run. There's no fighting! However, if you want that data streaming back to you, this is where you might think you want something more like WebSockets. For some use cases, this can be more efficient than having the client polling to see if the result of a long running process is ready. It all depends. Anyway, not advocating for anything here, just pointing out that I had the same worry about supporting a rich vocabulary of verbs, but then kind of realized it didn't matter because all verbs you want can be nouns. If you are using HTTP though, the REST verbs match up pretty nicely with how the protocol works, so it avoids inventing another abstraction to sit on top of it.

WClayFerguson 6y ago
You seem to realize that an RPC API design is totally separate concern from HTTP, and I agree with most of what you're saying, but then in your last sentence you say "REST verbs match up nicely" and can simplify your API. Respectfully, no it can't. REST doesn't remove abstraction layers, it creates abstraction layers. Whether you do REST or not you will have an interface between client and server, which has to be documented and have a well defined set of nouns and verbs, period. Can't be avoided. Removing my choice of verbs does NOT simplify things. If my API only needs CRUD verbs that's what I'll use. No problem. But forcing me into those 4 verbs, only, ever, and always (as pure REST does) is not a help, it's a hindrance.
- mattmcknight 6y ago
  By "REST verbs match up nicely", I meant REST verbs match up nicely with HTTP methods...(there are currently about 9 HTTP methods?). That's why it's not an additional abstraction, a POST is a POST. Compared to SOAP, which is where I came to it, it's tightly aligned with the transport. (People used to advocate for SOAP saying you could use it over SMTP...). If you are going to do a non-HTTP API, REST doesn't make a lot of sense. Anyway, I was still annoyed by the limited verbs 10 years ago after using REST for five years at that point. I even blogged about it, as I started doing HATEOAS about that time, so I really feel your annoyance. I've just discovered over time that the verb/noun thing is just stylistic, not an actual technical concern. All of your verbs can be nouns.
  - WClayFerguson 6y ago
    I've also done plenty of SOAP back in the day. I independently invented the equivalent of SOAP in an API back in 1998 where my RPC API used only one method, which was basically a "call(command)" for sending XML data upstream and getting an XML response (C++ app). The request XML had the "name" of the "verb" as part of the request. Basically a "command pattern". So what I do today is I use "REST APIs" (like in Java Spring, Axios/Ajax, etc.) but all my endpoints are named as "verbs" (not nouns), and the only HTTP verb I ever do is a "POST". So everything boils down to this: let myJsonReponse = api.doSomeVerb(myJsonRequest);

jayd16 6y ago

Creating nouns out of your RPC is actually powerful and transformative. Verbs are transitive but nouns can be queried, handled asynchronously etc. It feels like jumping through hoops but you end up with a more solid API for the web.

WClayFerguson 6y ago
I like code that's simple to understand like this: ``` let user = api.getUser(); user.setName("Clay"); api.saveUser(user); ``` That's just a basic RPC API. No one will ever convince me that turning all that into some kind of noun-based equivalent is better. The fact that a GET and a POST are HTTP verbs that match up to that is is meaningless to me because I could care less about the HTTP layer in my API design. APIs should be decoupled from all underlying architecture as much as possible. REST is about TIGHTLY COUPLING THEM as much as possible. Bad idea.
- jayd16 6y ago
  > No one will ever convince me Well for anyone else listening, a RESTful design would help you know whether you're creating or updating a user. You would know if you're allowed to repeat the request without side effects. That's useful in a distributed api where half open requests are inevitable.
  - WClayFerguson 6y ago
    I think with functional programming developers are capable of knowing whether they're creating or updating a user. However with REST I can't "transmogrify" a user. Do you know what a "transmogrification" is? No you don't. Because REST doesn't do that. It's a domain specific verb I made up. To force REST to work you'd have to invent a new noun called "transmogrify state", even if no one would have ever conceived of that state in a functional programming design. Whenever you end up inventing new objects specifically to work around architectural limitations, that's not a simplification. :) Functional Programming works. Nothing invalidates verbs just because you're doing them over HTTP, for example. Your API design should have no clue if it's running over HTTP or something else.

tuesdayrain 6y ago

>I mean if I need to run some reports it had better be called "runReports()" not some janky update of a state of some 'report' object to change it to 'running' state. So silly. REST is so jank. I fail to see how that's janky, it sounds like a great abstraction. I would have a 'createReports()' method that returns an array of Report objects that all correspond to a record in a database. Easy to query for the state, id, or any other details I might need. Doesn't get any cleaner than that in my opinion.

WClayFerguson 6y ago
Yes, we agree. What I meant is I'd have a verb that creates and returns some kind of "ReportContext" object, which sends back an "id" which I can then query status of later, for example. But no REST. My point is that the entire endpoint would be mostly verbs (like runReports) and use only the HTTP POST to communicate. So I'm "ignoring" the fact that it's running over HTTP, I would ignore every "rule" of REST, because REST offers nothing but hurdles to jump over.