Except for all of the cases where POST returns data, sure. There is absolutely no reason to destroy the result of creating a resource instead of returning the newly created resource with a flag "don't do that again".
You are using a perfectly good axe as a door stop then whining that your teaspoon isn't cutting down trees properly.
Meanwhile you're dulling the perfectly good axe to be sure that nobody cuts down your sacred tree.
With modern frameworks and Java level classiness (here, have a mappingfactory class that instantiates the mapping class that maps the data from the form into the object returned from the factory class that produced the object being created) what happens is more like
The POST creates a hospital, staffs it with receptionists, doctors, nurses, and so on. A pregnant woman (the request) goes in, the receptionist routes her to the OB ward where nurses help her into the stirrups and the doctor catches the baby. The doctor takes all the baby's stats, writes it on the birth certificate, drops the certificate into a pneumatic chute that whisks it away to safety (in the database) as the hospital and all its occupants are immediately vaporized by an explosion (if you're still using CGI, replace this with the entire sun going supernova. Add recreating the solar system to the beginning of the next request).
The GET creates a hospital, staffs it with receptionists, doctors, cloning technicians, and so on. A woman (the request) goes in, the receptionist routes her to the cloning ward where the woman hands over the birth certificate that had been mailed to her, the doctor looks over the certificate and checks to make sure she's really supposed to have it (or not, given the state of security these days) then pulls out a cloning tank and reconstitutes a baby that is identical in every way (ideally) to the original and hands it to the woman. As the woman leaves the hospital baby in tow, it explodes behind her, action movie style.
Or, y'know, you could just pass the new baby straight to a View and do all this with half the hospitals, doctors, receptionists and none of the cloning vats.
then I've got a 486 upgrade I'll donate for free.
Thanks! Once it can do the same task with half the number of requests, it'll work twice as well!
I think this is less a problem with the HTTP protocol
Using onload="history.pushState(null, null, '/user/31813812');" certainly works, but now pushing the "back" button is the landmine instead of pushing refresh (not to mention users that turn off javascript). Being able to use javascript to pretend you're doing what the HTTP procotol should have done does not make it not a problem with the protocol.
That said, the HTTP/1.1 protocol itself is fine. A user agent ought handle a 201 Created response exactly like this as a side effect (OK, so the response body is technically not a listing of places you can get the created object from, but it's supposed to be displayed to the user either way), but there are zero browsers implementing the Location part of it. Adding a response code explicitly for the purpose of "here is a response to display to the user right now, if the user wants to reload it, request this URL instead" would hopefully get browser developers to say "oh, I see why we're doing this" and do it. Doubly so when they're writing a new implementation for a new protocol. At this point, I'd argue that the best thing to do would be to add something like "311 Content With Future Redirect" so that browsers that don't implement it continue with 3xx POST-Redirect-GET semantics (losing nothing) and browsers that do understand it will work.
Will HTTP/2 have a response code that will cause the browser to display the page that is returned from the server AND change the "current url" (for bookmarking, refreshing etc) to an alternate Location? POST to/createnewuser, display the response immediately with the URL of/user/3813812. Refreshing loads/user/3813812, not re-POSTing to/createnewuser.
Right now, the current paradigm of having to either redirect every single POST request to a new URL or risking users too stupid to know that they really need to not press reload on the page after saving something is a drain on server resources one way and support resources the other.
It's hard to say. To be honest, to me they sound exactly like the non-answers I'd expect any executive officer to give. The fact they don't mention PRISM at all in reference to recent US government capability is definitely interesting, given that they used to openly state that TOR is weak against such widespread surveillance.
Does having a Netflix server in Comcast's data center cause Comcast to slow down Hulu? If so, Comcast probably ought to fix that. If not, then how is it prioritized?
How's Python 3 adoption coming along? (and they worked so hard to make it forwards and backwards compatible if you remember to put parentheses around your print arguments!)
Faraday cages are nice until you need to stick a wire through them to plug into the wall. Enjoy your battery life (and/or jiggawatt laser outside pointed through the mesh at a solar panel inside)
Slashdot Mirror
POST alters data, never retrieves it.
Except for all of the cases where POST returns data, sure. There is absolutely no reason to destroy the result of creating a resource instead of returning the newly created resource with a flag "don't do that again".
You are using a perfectly good axe as a door stop then whining that your teaspoon isn't cutting down trees properly.
Meanwhile you're dulling the perfectly good axe to be sure that nobody cuts down your sacred tree.
With modern frameworks and Java level classiness (here, have a mappingfactory class that instantiates the mapping class that maps the data from the form into the object returned from the factory class that produced the object being created) what happens is more like
The POST creates a hospital, staffs it with receptionists, doctors, nurses, and so on. A pregnant woman (the request) goes in, the receptionist routes her to the OB ward where nurses help her into the stirrups and the doctor catches the baby. The doctor takes all the baby's stats, writes it on the birth certificate, drops the certificate into a pneumatic chute that whisks it away to safety (in the database) as the hospital and all its occupants are immediately vaporized by an explosion (if you're still using CGI, replace this with the entire sun going supernova. Add recreating the solar system to the beginning of the next request).
The GET creates a hospital, staffs it with receptionists, doctors, cloning technicians, and so on. A woman (the request) goes in, the receptionist routes her to the cloning ward where the woman hands over the birth certificate that had been mailed to her, the doctor looks over the certificate and checks to make sure she's really supposed to have it (or not, given the state of security these days) then pulls out a cloning tank and reconstitutes a baby that is identical in every way (ideally) to the original and hands it to the woman. As the woman leaves the hospital baby in tow, it explodes behind her, action movie style.
Or, y'know, you could just pass the new baby straight to a View and do all this with half the hospitals, doctors, receptionists and none of the cloning vats.
then I've got a 486 upgrade I'll donate for free.
Thanks! Once it can do the same task with half the number of requests, it'll work twice as well!
Using onload="history.pushState(null, null, '/user/31813812');" certainly works, but now pushing the "back" button is the landmine instead of pushing refresh (not to mention users that turn off javascript). Being able to use javascript to pretend you're doing what the HTTP procotol should have done does not make it not a problem with the protocol.
That said, the HTTP/1.1 protocol itself is fine. A user agent ought handle a 201 Created response exactly like this as a side effect (OK, so the response body is technically not a listing of places you can get the created object from, but it's supposed to be displayed to the user either way), but there are zero browsers implementing the Location part of it. Adding a response code explicitly for the purpose of "here is a response to display to the user right now, if the user wants to reload it, request this URL instead" would hopefully get browser developers to say "oh, I see why we're doing this" and do it. Doubly so when they're writing a new implementation for a new protocol. At this point, I'd argue that the best thing to do would be to add something like "311 Content With Future Redirect" so that browsers that don't implement it continue with 3xx POST-Redirect-GET semantics (losing nothing) and browsers that do understand it will work.
Will HTTP/2 have a response code that will cause the browser to display the page that is returned from the server AND change the "current url" (for bookmarking, refreshing etc) to an alternate Location? POST to /createnewuser, display the response immediately with the URL of /user/3813812. Refreshing loads /user/3813812, not re-POSTing to /createnewuser.
Right now, the current paradigm of having to either redirect every single POST request to a new URL or risking users too stupid to know that they really need to not press reload on the page after saving something is a drain on server resources one way and support resources the other.
Invest in my scheme! Send me money and I'll send you slips of paper that say you own gold!
You'll have the choice of paying extra for Windows 366 on those years, or else leaving your computer off for an entire day.
Cmon big bucks no whammys no whammys...
I dunno, some navel guns are pretty powerful.
I think you mean /* Insightful */
Maybe he was going for imp -> impious than for im-pious.
It's hard to say. To be honest, to me they sound exactly like the non-answers I'd expect any executive officer to give. The fact they don't mention PRISM at all in reference to recent US government capability is definitely interesting, given that they used to openly state that TOR is weak against such widespread surveillance.
Does having a Netflix server in Comcast's data center cause Comcast to slow down Hulu? If so, Comcast probably ought to fix that. If not, then how is it prioritized?
A way to protect or extend your telomeres might be the only vaccine for death.
HeLa certainly appreciates it.
And attaching a brand name makes it any different? What makes Centrum better than CVS?
Probably someone who hasn't discovered --no-install-recommends yet.
Clearly they should form a new organization: Future Farmers of Luna.
Get it?
I don't have space in my apartment for a large black obelisk just sitting around being cool. Can I lay it on its side and use it as a table?
Clearly HD means that the audio is 1080 pees wide.
How's Python 3 adoption coming along? (and they worked so hard to make it forwards and backwards compatible if you remember to put parentheses around your print arguments!)
As I understand it, the cable would become an antenna for whatever's going on in the cage.
Death camp implies that they're interested in spending money on killing you when there's a perfectly serviceable gutter for you to crawl into.
"Trust us"
But does it run Windows?
In the US we gave our telcos massive tax cuts in the 90s in exchange for fiber rollout. The telcos took the money and ran.
Faraday cages are nice until you need to stick a wire through them to plug into the wall. Enjoy your battery life (and/or jiggawatt laser outside pointed through the mesh at a solar panel inside)