4 ms·

Not at all. Imagine a document editor. There are limits to the amount of data that can be passed via GET URLs. Without POST you could only have 2KB documents. I

by aristus 18y ago

Not at all. Imagine a document editor. There are limits to the amount of data that can be passed via GET URLs. Without POST you could only have 2KB documents. In Archivd we use POST via Ajax anywhere the user mutates data. It avoids the data length problem and makes it simpler to defend against CSRF attacks.

mlLK 18y ago
Imagine a document editor. For the web? Passing the entire document asynchronously? In Archivd we use POST via Ajax anywhere the user mutates data. See, I'm still new to AJAX and from the type of apps that I use and experiment with are generally broken down as independent events who pass values and who perform an xhr as each event is triggered. I guess as your app grows and the data your handling using this methodology (as GET) is suddenly just too complex to carry out on the client. Thanks for the input though.
- boucher 18y ago
  280 Slides uses an asynchronous POST (or PUT) request for saving documents. Just because the mechanism for generating requests has changed, that doesn't mean the mechanics of REST should be thrown out the window. REST is useful, and its how most of the infrastructure of the web works. It's useful to understand this, and try to build your applications appropriately.
- intranation 18y ago
  > For the web? Passing the entire document asynchronously? See Google Docs as an example of this.
- drawkbox 18y ago
  Ok even if you do independent events eventually you want to upload an image or a file which is not going to fit in GET very well, the url path is limited to 2k. POST you can pass much more information, also it is more secure in that is does not log the params and path in logs. Or maybe you POST to a REST url that has some params such as an api_key, then you post the data structure. Or you want to post a large JSON object of all data on a page. Again limits to GET, so people choose POST then. It depends on the situation.
bluefish 18y ago
Using POST doesn't necessarily make it simpler to defend against CSRF. You still need to use some kind of exclusive token shared between the client and server (e.g. a session id stored in a cookie). Imagine a poorly implemented site that doesn't prevent users from uploading js script blocks into the comments. A user could upload a script that creates a form and submits it via POST to your POST restricted endpoint, thus circumventing POST only protection. I'm assuming I've misread your comment as you use POST only and you're also doing proper CSRF protection right?

by aristus 18y ago

mlLK 18y ago

Imagine a document editor. For the web? Passing the entire document asynchronously? In Archivd we use POST via Ajax anywhere the user mutates data. See, I'm still new to AJAX and from the type of apps that I use and experiment with are generally broken down as independent events who pass values and who perform an xhr as each event is triggered. I guess as your app grows and the data your handling using this methodology (as GET) is suddenly just too complex to carry out on the client. Thanks for the input though.

boucher 18y ago
280 Slides uses an asynchronous POST (or PUT) request for saving documents. Just because the mechanism for generating requests has changed, that doesn't mean the mechanics of REST should be thrown out the window. REST is useful, and its how most of the infrastructure of the web works. It's useful to understand this, and try to build your applications appropriately.
intranation 18y ago
> For the web? Passing the entire document asynchronously? See Google Docs as an example of this.
drawkbox 18y ago
Ok even if you do independent events eventually you want to upload an image or a file which is not going to fit in GET very well, the url path is limited to 2k. POST you can pass much more information, also it is more secure in that is does not log the params and path in logs. Or maybe you POST to a REST url that has some params such as an api_key, then you post the data structure. Or you want to post a large JSON object of all data on a page. Again limits to GET, so people choose POST then. It depends on the situation.

bluefish 18y ago

Using POST doesn't necessarily make it simpler to defend against CSRF. You still need to use some kind of exclusive token shared between the client and server (e.g. a session id stored in a cookie). Imagine a poorly implemented site that doesn't prevent users from uploading js script blocks into the comments. A user could upload a script that creates a form and submits it via POST to your POST restricted endpoint, thus circumventing POST only protection. I'm assuming I've misread your comment as you use POST only and you're also doing proper CSRF protection right?