More Sending Behaviour options for request chaining
Improvement
At the moment the options are Always and When no responses The problem is for some APIs the resources I’m chaining from expires. I can’t use always as I don’t want to constantly be creating more of resources. I need to be able to perform various requests on one item, and when it expires I want to perform a single request to refresh it and let all the other requests chain of it again.
This could either be achieved by being able to set an Time To Live for request responses in the context of request chaining, or by allowing the HTTP status of the current request to kick off the chain.
At the moment I have to clear all the responses for the base API call each morning and it just feels tedious after magic of request chaining.
This should be possible to implement with a bit of work to the plugin system (need the ability to show additional parameters based on previous parameter selection)
Being able to resend when last request is older than x minutes/hours/days; and/or based on the response status code would be a great start and solve my problem with authentication.
However I have another problem which I think would need some other kind of solution. It still has to do with request chaining so I feel it’s appropriate to bring up here in the comments, but I can also make a new feature request if you folks feel it’s the better place.
First my problem:
My API is split into two sides: public facing and administrative/management side.
Every item in my api has a unique
slugand the public api works through the slug alone, think/api/v1/items/:slug/. I can also list the items at/api/v1/items/. Initially the slug variable is populated by getting the first result of the list, but it’s expected that the user will want to change this by hand to point to an item they are interested in.Additionally every item has an owner, and the administrative side is scoped by the owner id, like
/api/adm/users/:owner_id/items/:slug/. Myowner_idvariable is set up with request chaining to get/api/v1/items/:slug/and parse theowner_idfrom there.This all works great as long as I don’t mess with the slug: If I change the slug, I have to also remove the response where
owner_idis populated from.Now that I’ve rubber-ducked it down this way in text, I guess I could also solve this by the response status code when the administrative api returns 404… but I feel like a more elegant solution would be some kind of a dependency graph, where
owner_idrealizes that it’s stale because the URL it was fetched from has changed, and updates itself before a request fails because of that. Might be a lot of work though.MVP for me would be being able to manually enter an expiry period.
Advanced functionality would be parsing an expiry time from the response including from within a JWT.
https://yaak.app/blog/2025.7.0-beta.3
https://yaak.app/blog/2025.7.0