Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- As "just a guy that programs" (ok, now guides agents to program) and tries to follow the rules (with a big dose of pragmatism), this totally makes sense to me. This is also the first time I've seen or heard about this coming.
I like that we now have a way to not being forced to define Resources when we want to query. It always felt like I was missing something that there could be an infinite, defined-on-the-fly number of Resources for a "part" of a given Resource. Do I really want to define "all cats that sleep more than 20 hours a day and like sunbeams and want to eat breakfast at 3 am" as a Resource? (ok, we all know that is actually the full set of cats). I'm ok that you want to define that as a Resource but in my system, it makes more sense that Cats is the Resource and I just need some accepted way to query.
I like the implementation (again, as just a guy that programs). I don't see how it could have done it better or simpler which probably hides the complexity of getting there.
I also especially appreciate how the spec is written. Opening a spec, I wonder how far I'll get before I don't know what the heck they're talking about (and, again, as just a guy that programs). I don't think it's easy to write a spec that is complete and approachable like this. Really appreciate that.
by tonympls - The standards have always been a bit more abstract than you use in practice. Common practice prior to this would be /catsearch?sleep=20&sunbeams=yes&breakfast=0300 where the "resource" is /catsearch and the rest are query parameters, but you could also use /catsearch/sleep/20/sunbeams/yes/breakfast/0300 which looks like a "resource", but nobody is actually enforcing that it is a "resource".by inigyou
- I know agents are out of scope of this RFC but I love that this could easily be extended to make the JS EventSource to work on streaming AI queries.
Due to the need of bodies in requests, everyone uses POST and streaming results often use the text/event-stream protocol for responses. But this is technically a bad fit because no state is actually changing and because EventSource can only use GET for some obstinate reason. So many APIs reimplement the functionality with their own parser
by inlined - > https://www.rfc-editor.org/info/rfc10008/#section-2.8
Having a standard way to do pagination would be extremely useful. If we could add an items (or similar) range header type that would be excellent!
For example, in the HEAD response (and the QUERY response):
In the QUERY request:accept-ranges: items items-length: 342Range: items=0-9 - The pagination is not always done with page numbers, sometimes there are "next" and "previous" tokens.by codedokode
- Use the QUERY method in your http query to query search results. Do not add query parameters.
I think the name is confusing because the term 'query' is already used to refer to http requests in general.
Just the title of the RFC confused me.
by smashed - Yeah, and it doesn't even have to be a query, it could be an idempotent effect. I think they'd be better off calling it IPOST (for idempotent post).
Edit: ah, they declare QUERY as "safe" meaning no side effects, for cacheability. My mistake.
by rehevkor5 - > the term 'query' is already used to refer to http requests in general
In what circles is this the case? I sometimes colloquially refer to a GET request as a query, but definitely not so on a POST, PUT or DELETE.
by comfydragon - Wait, it's already past 10 thousand?
- Someone has an ambiguous bet predicting when RFC 10000 will be published, but the numbers went straight from 9998 to 10008. No-one wins!
https://manifold.markets/CollectedOverSpread/when-will-rfc-1...
by rhplus - This makes me happy tbh, I was never a fan of creating `POST /search` endpoints when working with robust APIsby toybeaver
- If this is actually going to replace GET requests w/ query strings in the wild, Im very much hoping for browser bookmarks to support keeping request parameters.by andltsemi3
- That's a good point, I do like to be able to bookmark specific issues (like in Jira I bookmark 'all issues that are assigned to me and not done' )by anitil
- Probably won't. Probably will replace whenever POST is currently used for a query.by inigyou
- Aside: Wow, we’ve hit 5-digit RFC numbers now!by drob518
- > GET request with a body was heavily considered by the IETF working group, but it was ultimately rejected in favor of creating the new QUERY method. The decision to create a distinct method came down to historical interoperability issues and strict compliance with the core architectural definitions of HTTP.
I've been sending request body along GET method for years now
by piterrro - what do servers/proxies do when they don't recognise the verb?by _betty_
- I work with a custom own maded web framewrok for Java (from before Spring was a thing!). A funny thing it's that treats GET and POST petitons identical when try to recover parameters from the petitions. So GET and POST get parametertes from URL and from BODY. And this made some weird bugs many years ago, when in some case, we got repeated parameters in URL and BODY, trigering the framewrok to think that must put it on a List and pass it to the service method.by Zardoz84
- It does seem like a boil-the-ocean "fix". The entire planet has been kludging this with GET or POST as appropriate for the entire lifetime of HTTP, and now there's a proposal to do something that looks identical to POST but with slightly different semantics? So in exchange for solving a problem that's been dealt with (if not perfectly) forever you'd need to convince the entire world to adopt a new, incompatible mechanism? I'll give this one as much of a chance as BEEP.
You've never heard of BEEP? Well, that's why.
- Apparently some load balancers drop the body.by huskyr
- It's not a great idea. I wrote something a few years ago if it's interesting:by treve
- this was the response the last time this came up here.
you can do all kinds of nonstandard stuff if you control the server, the client, and any steps in between. the point of standards is for when you don't control it all.
put your server behind a managed load balancer or a caching proxy, and your get requests with bodies aren't going to do so well anymore.
by notatoad - > I've been sending request body along GET method for years now
Generally not a great idea. With some http implementations this is not even possible (for example, fetch)
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...
> You cannot include a body with GET requests
And transparent caching might result in weird issues.
by preisschild - Just in case anyone wants to pretend it's still that other century:by ynac
- beautiful formatting. I should crib this style template for internal work memos, it's timeless.by riffic
- I'll forever love a long, totally plain text document like this. So many good times with video game FAQs as a kid. It really is a superior form of information in a lot of ways (not all).by jjice
- I wonder if HTML forms will add support for QUERY:
This would avoid the annoying re-submission warnings you're getting if you refresh a page that was returned by a POST form submission, since QUERY is required to be idempotent.<form action="..." method="query">by CodesInChaos - Forms, HTTP implementations, public API surfaces, and all for what exactly. Introducing a new verb for this feels profoundly misplacedby 100ms
- Depends whether your form submission should expect side effects or not. Most forms submissions have side effects. If the effect is truly idempotent, wouldn't PUT be a better verb? That is also supposed to be idempotent.by tempfile
- They never added support for any other verbs, but it's a brave new world, so who knowsby paradox460