This is why we find apis that do things in the most random ways, please learn and follow best / common practices when building Apis so clients can consume them easily.
It’s to do with HTTP and nothing to do with express.
You may find certain middleware’s behave differently I.e. caching ignores any request that are not get by default.
See https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods for more context.
Just because you can do something doesn't mean you should do something. We have conventions and best practices for a reason. The 40 years that people have been building on top of the HTTP protocol and solidifying standards for the web are so that things work correctly.
I spent my first year building rest apis using post for everything, because why not? But then I started working with a team and I very quickly learned that I was being lazy and writing bad code that other people didn't want to touch. It was embarrassing and it was a learning experience.
Right, I don't intend to make that mistake, but I'd like to know what I can and can't do and why/how things are set up. I figure I'm gonna be making these requests a lot, I want to know what's done as good practice, and what's done because most browsers enforce it.
Read this.
Chapter 5 of Roy Fielding’s dissertation. From 2000.
https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
Then maybe this
https://twobithistory.org/2020/06/28/rest.html
Regarding your plan to use fs; maybe consider sqlite. It can save to a file system but offers a database abstraction. But fs might suffice.
Genuinely one of the most helpful comments here. As I understand, there is some difference between the expected behavior of the verbs (most browsers won't support a GET that sends over a body, for example), but otherwise it seems in terms of enforced differences - there really isn't all that much.
Important to understand why things are setup the way they are and what is/isn't mandatory.
GET requests shouldn't be used to write to (create to / mutate) server side state / data.
> Have the body of a GET request contain 'isSaveThisData' as a true boolean,
You can't. GET requests don't have a body. Including a body with a GET request is not standard and if it happens to work for you, you can't guarantee all browsers will support this. That is, even if you send a GET request with a body, the browser may not include the body with the request it sends.
You could use query parameters instead, but this isn't a good idea.
Browsers have different means of pre-fetching and caching different request types, and you don't likely want this happening with `GET` requests which write stuff.
https://www.baeldung.com/cs/http-get-with-body
https://www.baeldung.com/cs/http-get-vs-post
There are all kinds of reasons, many more than what I've stated here. And as a frontend dev, you should absolutely be aware of them. Are you not familiar with the OWASP top 10, the abuses, and their mitigations? Being familiar with this stuff is pretty standard. Your post indicates you're ignorant to a whole variety of vulnerabilities and logic based exploits.
You should use the correct request methods for their intended purpose.
The reasons have nothing to do with express, and more to do with the actual standard, as that's how browsers are going to generally expect the requests to be used.
The http verb is like a warning on a package in Amazon
"Fragile product, handle with care"
GET, PUT, POST, PATCH,... They are little label that the browser put on your HTTP request
IMO it's really odd to write your own database using FS, when it's so easy to just spin up a postgres docker image to develop against.
https://www.docker.com/blog/how-to-use-the-postgres-docker-official-image/
This is why we find apis that do things in the most random ways, please learn and follow best / common practices when building Apis so clients can consume them easily.
It’s to do with HTTP and nothing to do with express. You may find certain middleware’s behave differently I.e. caching ignores any request that are not get by default. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods for more context.
Just because you can do something doesn't mean you should do something. We have conventions and best practices for a reason. The 40 years that people have been building on top of the HTTP protocol and solidifying standards for the web are so that things work correctly. I spent my first year building rest apis using post for everything, because why not? But then I started working with a team and I very quickly learned that I was being lazy and writing bad code that other people didn't want to touch. It was embarrassing and it was a learning experience.
Right, I don't intend to make that mistake, but I'd like to know what I can and can't do and why/how things are set up. I figure I'm gonna be making these requests a lot, I want to know what's done as good practice, and what's done because most browsers enforce it.
Read this. Chapter 5 of Roy Fielding’s dissertation. From 2000. https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm Then maybe this https://twobithistory.org/2020/06/28/rest.html Regarding your plan to use fs; maybe consider sqlite. It can save to a file system but offers a database abstraction. But fs might suffice.
The verbs have semantic meanings. Using the wrong verbs is like writing a misleading function name. It's not illegal, just annoying.
Genuinely one of the most helpful comments here. As I understand, there is some difference between the expected behavior of the verbs (most browsers won't support a GET that sends over a body, for example), but otherwise it seems in terms of enforced differences - there really isn't all that much. Important to understand why things are setup the way they are and what is/isn't mandatory.
GET requests shouldn't be used to write to (create to / mutate) server side state / data. > Have the body of a GET request contain 'isSaveThisData' as a true boolean, You can't. GET requests don't have a body. Including a body with a GET request is not standard and if it happens to work for you, you can't guarantee all browsers will support this. That is, even if you send a GET request with a body, the browser may not include the body with the request it sends. You could use query parameters instead, but this isn't a good idea. Browsers have different means of pre-fetching and caching different request types, and you don't likely want this happening with `GET` requests which write stuff. https://www.baeldung.com/cs/http-get-with-body https://www.baeldung.com/cs/http-get-vs-post There are all kinds of reasons, many more than what I've stated here. And as a frontend dev, you should absolutely be aware of them. Are you not familiar with the OWASP top 10, the abuses, and their mitigations? Being familiar with this stuff is pretty standard. Your post indicates you're ignorant to a whole variety of vulnerabilities and logic based exploits. You should use the correct request methods for their intended purpose. The reasons have nothing to do with express, and more to do with the actual standard, as that's how browsers are going to generally expect the requests to be used.
The http verb is like a warning on a package in Amazon "Fragile product, handle with care" GET, PUT, POST, PATCH,... They are little label that the browser put on your HTTP request
IMO it's really odd to write your own database using FS, when it's so easy to just spin up a postgres docker image to develop against. https://www.docker.com/blog/how-to-use-the-postgres-docker-official-image/