Just to make sure I understand your use case…
I think there’s a slight miscommunication, i.e., different workflow than you describe. Our current application uses a
dcc.Upload component (with an associated callback) that allows the user to do what you describe: drop or select a file where “the app responds by filling in the main portion of the page with processed results of that file and controls to interact with that processed data”. This is correct and it works as intended. Dropping a data file is the first action any user would normally take. The callback looks more or less like:
# and so on
def process_file_and_update_ui(contents, filename):
# do something fun with the file and update the UI
return output1, output2, etc
However, in addition to this manual usage, the client wants to also connect our application to some of their other services. They asked if we could expose an endpoint (e.g.,
/upload) that they could target programmatically with file data, which then would cause the application page to load in the same state as if the above callback fired. A concrete example is imagine a chat service where users can share files with one another, but now they can call up an embedded version of our app (
iframe) with the file of interest already loaded.
I will confess to being rusty on the ins and outs of request protocols and how endpoints are typically engineered, so I may be overlooking something. Now that I think about it more carefully, I’m not sure how possible it is to send this data and expect the page to load using said data… I’m realizing that’s not how POST works
I’ll try to think about this (and study up) a bit more. Hope that explains it better and curious if you have any insights.