6 ms·

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

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.
  - jayd16 6y ago
    You're right. No one knows what rules apply to transmogrification. That's why people use the http verbs to consistently create and edit things without having to look up the caching and idempotency rules of every random thing your API does. If your API had a /transmogrification/<id> resource. I would know how to query its state and possibly edit it. I have a clear place to look for previous transmogrifications without crating a new one and I even have a nice query syntax support. Or maybe you don't support GET and return a 405 response. That's ok too.
    - WClayFerguson 6y ago
      You basically just explained how REST works. :) * Limits number of verbs to CRUD ones (HTTP). * Makes every verb into a noun. * Tightly couples HTTP-codes into your API. * Requires creation of many endpoints you don't really need. * Makes it awkward to have a single request that updates multiple different types of objects, or queries different types of data. yeah, I don't want any of the above in my life.
mattmcknight 6y ago
I think that's a bad example, because it almost perfectly matches up with REST. user = UserApi.get(id) user.name = "Clay" UserApi.put(user) Does using put instead of save really bother you that much? The tight coupling doesn't matter if you are building a web service. HTTP is how they work.
- WClayFerguson 6y ago
  What bothers me is that if I have a verb called "transmogrify" in my API's domain language the REST purists will try to tell me not to use that verb, because some preexisting generic CRUD-type verb can be made to work instead. Sorry, no, that's awkward.
dragonwriter 6y ago
> 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. REST is a protocol-neutral architectural pattern, so, yes, you should care less about the specific protocol and it's verbs. REST is about resource representation (the nouns and the ways they are represented as data) driving everything, not wire protocol verbs. HTTP is itself a REST API built on top of TCP/IP, but other REST APIs don't have to be built on top of HTTP, or even tied to a single underlying protocol. > APIs should be decoupled from all underlying architecture as much as possible. REST is about TIGHTLY COUPLING THEM as much as possible. No, it's not, even approximately.
- WClayFerguson 6y ago
  If REST is "not even approximately" coupled to HTTP, then how do you explain that people attempt to use the fixed set of CRUD-type of verbs (GET, POST, etc.)? Just a coincidence I guess. lol.
  - dragonwriter 6y ago
    > If REST is "not even approximately" coupled to HTTP, then how do you explain that people attempt to use the fixed set of CRUD-type of verbs (GET, POST, etc.)? REST over HTTP uses standard HTTP methods with their HTTP-defined semantics rather than unnecessary ad hoc, API-specific extensions because, well, first, why would you do anything else if you want to use a standardized underlying protocol? And second because: “A REST API should not contain any changes to the communication protocols aside from filling-out or fixing the details of underspecified bits of standard protocols, [...]” https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...
    - WClayFerguson 6y ago
      I consider HTTP the 'pipe' over which the data is marshalled. It has it's own error codes, it's own verbs, and it's own protocol that has nothing whatsoever to do with my API for my APP and that's the way I want to keep it. I do an HTTP "post" to send up a JSON object as a request, and I get a JSON object back as the reply. No one is going to tell me there's a "simpler" way. There isn't. For example, if I need to delete data, I'll call "deleteSomething" as an endpoint. I could care less if HTTP has a delete in it's language, because I don't want/need any of that coupled into my API or affecting my API in any way whatsoever. That way my API can be moved to some non-HTTP pipe at some point and it will remain unchanged. It's just like how in good OOP you ideally code to 'interfaces' rather than coding to 'objects' directly. Here's an example controller: https://github.com/Clay-Ferguson/quantizr/blob/master/src/main/java/org/subnode/AppController.java https://github.com/Clay-Ferguson/quantizr/blob/master/src/ma... You can tell it's perfectly type-safe on both client (TypeScript) and server (Java), and the API itself doesn't have any clue it's even be running over HTTP, and that's a good thing.

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.
- jayd16 6y ago
  You're right. No one knows what rules apply to transmogrification. That's why people use the http verbs to consistently create and edit things without having to look up the caching and idempotency rules of every random thing your API does. If your API had a /transmogrification/<id> resource. I would know how to query its state and possibly edit it. I have a clear place to look for previous transmogrifications without crating a new one and I even have a nice query syntax support. Or maybe you don't support GET and return a 405 response. That's ok too.
  - WClayFerguson 6y ago
    You basically just explained how REST works. :) * Limits number of verbs to CRUD ones (HTTP). * Makes every verb into a noun. * Tightly couples HTTP-codes into your API. * Requires creation of many endpoints you don't really need. * Makes it awkward to have a single request that updates multiple different types of objects, or queries different types of data. yeah, I don't want any of the above in my life.

mattmcknight 6y ago

I think that's a bad example, because it almost perfectly matches up with REST. user = UserApi.get(id) user.name = "Clay" UserApi.put(user) Does using put instead of save really bother you that much? The tight coupling doesn't matter if you are building a web service. HTTP is how they work.

WClayFerguson 6y ago
What bothers me is that if I have a verb called "transmogrify" in my API's domain language the REST purists will try to tell me not to use that verb, because some preexisting generic CRUD-type verb can be made to work instead. Sorry, no, that's awkward.

dragonwriter 6y ago

> 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. REST is a protocol-neutral architectural pattern, so, yes, you should care less about the specific protocol and it's verbs. REST is about resource representation (the nouns and the ways they are represented as data) driving everything, not wire protocol verbs. HTTP is itself a REST API built on top of TCP/IP, but other REST APIs don't have to be built on top of HTTP, or even tied to a single underlying protocol. > APIs should be decoupled from all underlying architecture as much as possible. REST is about TIGHTLY COUPLING THEM as much as possible. No, it's not, even approximately.

WClayFerguson 6y ago
If REST is "not even approximately" coupled to HTTP, then how do you explain that people attempt to use the fixed set of CRUD-type of verbs (GET, POST, etc.)? Just a coincidence I guess. lol.
- dragonwriter 6y ago
  > If REST is "not even approximately" coupled to HTTP, then how do you explain that people attempt to use the fixed set of CRUD-type of verbs (GET, POST, etc.)? REST over HTTP uses standard HTTP methods with their HTTP-defined semantics rather than unnecessary ad hoc, API-specific extensions because, well, first, why would you do anything else if you want to use a standardized underlying protocol? And second because: “A REST API should not contain any changes to the communication protocols aside from filling-out or fixing the details of underspecified bits of standard protocols, [...]” https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...
  - WClayFerguson 6y ago
    I consider HTTP the 'pipe' over which the data is marshalled. It has it's own error codes, it's own verbs, and it's own protocol that has nothing whatsoever to do with my API for my APP and that's the way I want to keep it. I do an HTTP "post" to send up a JSON object as a request, and I get a JSON object back as the reply. No one is going to tell me there's a "simpler" way. There isn't. For example, if I need to delete data, I'll call "deleteSomething" as an endpoint. I could care less if HTTP has a delete in it's language, because I don't want/need any of that coupled into my API or affecting my API in any way whatsoever. That way my API can be moved to some non-HTTP pipe at some point and it will remain unchanged. It's just like how in good OOP you ideally code to 'interfaces' rather than coding to 'objects' directly. Here's an example controller: https://github.com/Clay-Ferguson/quantizr/blob/master/src/main/java/org/subnode/AppController.java https://github.com/Clay-Ferguson/quantizr/blob/master/src/ma... You can tell it's perfectly type-safe on both client (TypeScript) and server (Java), and the API itself doesn't have any clue it's even be running over HTTP, and that's a good thing.