I agree about creating some kind of "context object" that represents the status of a long running report, that exists for the duration of the report and can be

I agree about creating some kind of "context object" that represents the status of a long running report, that exists for the duration of the report and can be checked later. It's a very common pattern I've used a lot myself. Where REST makes that awkward is that many "verbs" I want to use in my API result in multiple such objects being created on a server, and multiple objects being returned (in some wrapper class), and that's awkward with REST because REST is all about making those nouns directly accessible. I don't want that. I want a vocabulary of actions. My client "does things". Doing is a verb. Verbs operate on nouns. The nouns will all exist but they themselves aren't the API. My other gripe is that I don't want the tech stack dictating to me ahead of time what my verbs are. Some of my verbs might do a create, and update, and some deletes, all in one verb as part of a transaction. There's no such thing as "Is this a create or an update or a delete API call?" It might be all those simultaneously. Each API call should have a unique Request object and and Response object. When your request/response are specific verbs, you can then later rename the verbs and easily add additional info to the Request and/or the Response without redesigning all your objects. Objects should be designed to model the data itself and NOT have any direct relationship to the API. Objects are in the language of the API verbs, but they don't control it.