3 ms·
Mostly common-sense things, but I can't wait for the community to stop trying to use PUT, PATCH, DELETE and the like. There's a reason that in 2022 web forms on
by BulgarianIdiot 5y ago
Mostly common-sense things, but I can't wait for the community to stop trying to use PUT, PATCH, DELETE and the like. There's a reason that in 2022 web forms only support GET and POST (and implicitly, HEAD).
- jahewson 5y agoWhat is the reason?
- runarberg 5y agoI don’t know what OP thinks is the reason, but the actual reason is CORS. Web Devs (such as me) have asked for e.g. DELETE as an acceptable formmethod (e.g. https://github.com/whatwg/html/issues/3577 https://github.com/whatwg/html/issues/3577) however WHATWG always pushes back citing security concerns such as CORS. I suspect this is not what OP had in mind since it is trivial to send a DELETE request with a simple JavaScript: <button onclick="fetch('/api/resource/42', { method: 'DELETE' })"> Delete </button>
- egberts1 5y agoRight. If CORS can be weakened in any simple way with that HTRP-DELETE method, then your database could simply disappeared via HTTP-DELETE method. Besides, webmasters’ HTTP DELETE method is a different domain scoping issue than the web developers’ HTML/JavaScript FORM deleteThis row-entry approach. I marvel at designers trying to flatten the scoping/nesting of abstractions without factoring apart the disparate error and protocol handling.
- jimbob45 5y agoAre you saying dump DELETE because you should instead logically delete it with an IsDeleted column passed in via POST?
- djbusby 5y agoOr POST to '/resource/id/delete'? That's my least favourite pattern
- deleted 5y ago[deleted]
- boredtofears 5y agoHuh? There’s full browser support for all of those verbs. What is the argument for not supporting them?
- BulgarianIdiot 5y agoThe HTTP request APIs pass through any method name you write. The HTML forms only support GET and POST. Try it.
- inopinatus 5y agoThere is no mention of HTML in these recommendations. The recommendation is perfectly good for any API using HTTP as the substrate. The wisdom of using HTTP as a protocol substrate is questionable, but having made that decision the verbs it supplies work perfectly well. Incidentally, the HTML living standard supports three form methods, not two: get, post, and dialog. Which rather reinforces the point that HTML != HTTP.
- boredtofears 5y agoHow is that relevant to REST API’s? You don’t generally post to rest endpoints from a form anyways for a lot of good reasons.