Exactly.

Methods, headers, status-codes, content-types, bodies, paths, querystrings. So many variables, hidden magic, combinations of variables, mismatched implicit assumptions. So much flexibility, so much trouble for nothing. 

 Meh, GET|POST /path is bare minimum, possibly with an host header for virtual hosts. There rest is pretty much optional sugercoating. Your reasoning goes the same for all nips beside 01. No need for the rest in essence and it is the same for http. And then devs start adding features 🤣 

 I think it’s more the restrictiveness, opinionatedness, or ambiguity with these methods comparatively. 

 Yeah, you could only do with get or post, it just that these two cause the browser to act differently. The other methods are (more or less) degrees of freedom expression. I'd say the nips are not much different technically, may be semantically there is some difference dunno, but to go religic about it goes a bit far. 

 the devs must be stopped! 

 agree. 

I've been fighting forever against the innumerable possible combination for HTTPS + CORS + Cookies options (domain, secure, sameSite...) 

 Indeed, I forgot these other nasty things. Also redirects. 

 PUT: a file as is to a given path that you decide, such that the result is always the same no matter how many times you make the request.

Patch: usually append a file with some data, unlike PUT, number of requests matter.

POST: a form or an input, that the backend will handle as it sees fit, and you don't know the URL of the resource that the backend may or may nor create, for example you POST a request to order something, and the backend responds with the ID of the order to keep track of later. obviously the number of times you order something matters.

You can make fun of HTTP semantics, but you will just end up reinventing them in your new RPC, and force people to learn your new semantics because you didn't want to learn the old ones.

nostr:note14mxl0r96vk9spzzjd52s3em4jtz7k7rzqglyjt57ptfuldft4qfs54sg4v