5 ms·

Sigh. I hope this is satire. Or this person is only referring to their personal projects. Otherwise, I agree with their premise and suggest they find a differen

Sigh. I hope this is satire. Or this person is only referring to their personal projects. Otherwise, I agree with their premise and suggest they find a different career. HTTP Verbs? You really can't get more basic. At least you could try to wrap your brain around the idea that GET reads and POST writes. Not using SQL? Okay. You're spending a lot of time and effort hand-rolling your own shitty database. The combination of things suggests to me they have can't or don't want to deal with with non-trivial mental models. Things like transforming data between layers or figuring out how someone else will read your code. The next person to work on their stuff is going to have a massive headache figuring out what "made sense" to this person.

taneq 3y ago
> The combination of things suggests to me they have can't or don't want to deal with with non-trivial mental models. You mean… they’re stupid? Like they say in their title?
- kayodelycaon 3y ago
  Being limited in time, effort, or ability isn't stupid. I've got my own mental hardware limitations with reading math and some functional programming languages. Bad enough I don't put in the effort to learn certain things. Now, writing an article conflating limitations or lack of desire with intelligence shows... poor self-awareness. But yeah, I prefer not to say stupid when I can be more specific. :)
bedobi 3y ago
> HTTP Verbs? You really can't get more basic. Every REST API codebase I've ever worked on would like a word. There's TONS of subtleties that determine whether you should be creating a GET, POST, PUT or PATCH for many different use cases. And this isn't even taking into account the hundreds and hundreds, maybe thousands of endpoints I've come across that were obviously wrong, but some Senior or even Principal dev had somehow managed to completely botch it - NOT a rare occurence.
- kayodelycaon 3y ago
  I didn't say they needed to use REST. REST is a huge mess. You can simplify it to GET = doesn't change stuff, POST = changes stuff. Basic HTML form tag stuff. For the few things in-between like self-expiring links or counters recording how many times a thing was viewed can get tossed into GET because the data you're retrieving isn't being modified. (Search can be POST if you don't like query parameters in your urls.)
  - User23 3y ago
    GET: get a thing from a place. PUT: put a thing in a place. POST: create a new place, put a thing there, and tell me its location. DELETE: delete the contents of an existing place. The biggest subtlety I can think of is deciding whether PUT to a place that doesn't exist is valid, and whether DELETE of a place should delete just the object or also the place too, if PUT is only valid for existing places. How to handle that subtlety is application dependent. Personally I like to architect RESTful services such that POST isn't necessary since it's hard to make it idempotent, but sometimes POST is the most comprehensible interface. Also, I wouldn't bother using REST at all unless I was going to make everything fully discoverable via hypertext[1]. However that's not to say there aren't soundly designed non-RESTful ways to use the HTTP application protocol. [1] https://en.wikipedia.org/wiki/HATEOAS https://en.wikipedia.org/wiki/HATEOAS
kardianos 3y ago
I'm okay with it until the database. For http verb, I'm onboard with just using POST for everything. The database is one area that you need more care. Even if just SQLite, storage persists and especially if this is for a company, needs to persist past you.
- Supermancho 3y ago
  Unless there's a compelling reason...like a use case for caching (your server or an intermediate) or high volume (POSTs are larger requests), POST for everything is a good default.
  - Ireallyapart 3y ago
    [dead]
  - collyw 3y ago
    Debugging is easier with GET requests, where you can see what is being sent to the server. It's not a huge win, but it's better than POST for everything in my experience.
    - yurishimo 3y ago
      What do you mean? You can inspect POST request payloads in browser devtools just as easily as GET requests.
      - collyw 3y ago
        It's far faster when you can look at the URL and see the parameters. I have worked on systems with both and I didn't like everything as a POST. If you want to get a page with list of objects with a filter it's a lot easier to copy paste a URL than it is to fart about in developer tools and try top recreate the POST request.
        Supermancho 3y ago
waboremo 3y ago
Yeah I really hope this is exclusive to personal throwaway projects. Otherwise such thinking can land you and your potential users/clients in very hot water. A belief like avoiding SQL because is too complicated indicates to me you're incapable of handling data appropriately. Again, totally OK if you're smart enough to understand that you're not going to be using user data anyways maybe saving a theme variable here and there. But none of that is indicated in the article, and is why I'm so confused why the comments ITT are supportive.
908B64B197 3y ago
> Not using SQL? Okay. You're spending a lot of time and effort hand-rolling your own shitty database. I've seen this before. It crashed and corrupted most files because the author didn't understand how file IO really worked (he also created a ramdisk thinking it would be faster). Fortunately, someone took a memory dump of the process some times before and most data was recovered.

taneq 3y ago

> The combination of things suggests to me they have can't or don't want to deal with with non-trivial mental models. You mean… they’re stupid? Like they say in their title?

kayodelycaon 3y ago
Being limited in time, effort, or ability isn't stupid. I've got my own mental hardware limitations with reading math and some functional programming languages. Bad enough I don't put in the effort to learn certain things. Now, writing an article conflating limitations or lack of desire with intelligence shows... poor self-awareness. But yeah, I prefer not to say stupid when I can be more specific. :)

bedobi 3y ago

> HTTP Verbs? You really can't get more basic. Every REST API codebase I've ever worked on would like a word. There's TONS of subtleties that determine whether you should be creating a GET, POST, PUT or PATCH for many different use cases. And this isn't even taking into account the hundreds and hundreds, maybe thousands of endpoints I've come across that were obviously wrong, but some Senior or even Principal dev had somehow managed to completely botch it - NOT a rare occurence.

kayodelycaon 3y ago
I didn't say they needed to use REST. REST is a huge mess. You can simplify it to GET = doesn't change stuff, POST = changes stuff. Basic HTML form tag stuff. For the few things in-between like self-expiring links or counters recording how many times a thing was viewed can get tossed into GET because the data you're retrieving isn't being modified. (Search can be POST if you don't like query parameters in your urls.)
- User23 3y ago
  GET: get a thing from a place. PUT: put a thing in a place. POST: create a new place, put a thing there, and tell me its location. DELETE: delete the contents of an existing place. The biggest subtlety I can think of is deciding whether PUT to a place that doesn't exist is valid, and whether DELETE of a place should delete just the object or also the place too, if PUT is only valid for existing places. How to handle that subtlety is application dependent. Personally I like to architect RESTful services such that POST isn't necessary since it's hard to make it idempotent, but sometimes POST is the most comprehensible interface. Also, I wouldn't bother using REST at all unless I was going to make everything fully discoverable via hypertext[1]. However that's not to say there aren't soundly designed non-RESTful ways to use the HTTP application protocol. [1] https://en.wikipedia.org/wiki/HATEOAS https://en.wikipedia.org/wiki/HATEOAS

kardianos 3y ago

I'm okay with it until the database. For http verb, I'm onboard with just using POST for everything. The database is one area that you need more care. Even if just SQLite, storage persists and especially if this is for a company, needs to persist past you.

Supermancho 3y ago
Unless there's a compelling reason...like a use case for caching (your server or an intermediate) or high volume (POSTs are larger requests), POST for everything is a good default.
- Ireallyapart 3y ago
  [dead]
- collyw 3y ago
  Debugging is easier with GET requests, where you can see what is being sent to the server. It's not a huge win, but it's better than POST for everything in my experience.
  - yurishimo 3y ago
    What do you mean? You can inspect POST request payloads in browser devtools just as easily as GET requests.
    - collyw 3y ago
      It's far faster when you can look at the URL and see the parameters. I have worked on systems with both and I didn't like everything as a POST. If you want to get a page with list of objects with a filter it's a lot easier to copy paste a URL than it is to fart about in developer tools and try top recreate the POST request.
      - Supermancho 3y ago

waboremo 3y ago

Yeah I really hope this is exclusive to personal throwaway projects. Otherwise such thinking can land you and your potential users/clients in very hot water. A belief like avoiding SQL because is too complicated indicates to me you're incapable of handling data appropriately. Again, totally OK if you're smart enough to understand that you're not going to be using user data anyways maybe saving a theme variable here and there. But none of that is indicated in the article, and is why I'm so confused why the comments ITT are supportive.

908B64B197 3y ago

> Not using SQL? Okay. You're spending a lot of time and effort hand-rolling your own shitty database. I've seen this before. It crashed and corrupted most files because the author didn't understand how file IO really worked (he also created a ramdisk thinking it would be faster). Fortunately, someone took a memory dump of the process some times before and most data was recovered.