RFC for progress info in API calls? (tired of spinners)

Question

As the web we build (especially with the rise of GenAI & LLMs) becomes more and more dependent on API calls, I find it exceedingly frustrating that there are spinners absolutely everywhere, when it's "just" an informational disconnect - at some point in the stack it is / should be fairly well known how long something is going to take, we "just" don't propagate that information to the end user.So here's a tentative proposal: add an HTTP header like "X-Wants-Progress: 1" to the request indicating that the client wants progress information.A compliant server then includes a "X-Has-Progress: 1" header in its response and streams newline delimited numbers-as-strings in the [0.0-100.0] range as progress is made.Floats allowed, monotonically increasing, same number can be repeated, clients should protect themselves by updating with max(old_value, new_value).Once the progress part has completed, an empty newline is inserted and the real HTTP result is appended, status code, headers, body and all.This way clients and servers can opt-in to being "progress capable", and if you ensure you have that capability all the way through then you can switch from the dreaded spinner-of-death to a smooth progress bar.Thoughts?

schoen · Accepted Answer

Wasn't there a deprecation of the X- prefix in protocol headers?
Other thoughts:
You could probably make this play better with HTTP libraries by returning the header on an existing HTTP message, instead of changing the overall reply semantics. It's a little less efficient, but probably much more broadly compatible.
You could also have min-est-completion-time and max-est-completion-time rather than a percentage (partly to address people's concerns about the uncertainty or unknowability of overall progress as a percentage). Perhaps these could customarily be described as 90% intervals (or they could explicitly include a confidence estimate! like "90% of requests at this approximate degree of completion were completed within 7 and 32 seconds").

codegeek · Answer

API calls cannot have deterministic progress calculated in advance due to various factors like current system resources available, load, amount of data stored and various other things that can impact the time it takes to finish an API call. So I don't see how you can get a progress percentage out of such call. Spinners are the only way as of now. It is not always like a File upload where you know the size of the file and the chunks uploaded to the server already.

verdverm · Answer

This is too complex, difficult, and case dependent to make it a standard that requires implementation by frameworks. Nothing in the system can know how long each other part will take, let alone what downstream parts will be used to serve a request... so what float value should it be sending back when?

ra0x3 · Answer

I think you might be confusing application level and protocol level features? Of course you could always add custom headers (X-Wants-Progress) in your application. But the protocol (HTTP) doesn't really have insight into (or care about) any of your application context per se :)

al2o3cr · Answer

at some point in the stack it is / should be fairly well known how long something is going to take You should cite sources for a statement like this, because it doesn't seem like it's always true for interacting with a third-party API