A way to chain requests?
Hi!
It would be great to be able to chain two requests in order for the first one to obtain a JWT token that can be used in the second request, in an Authorization header in my case.
Or in a more generic way: to have the possibility to store the data we get from a request, and use it in the next request. That would open a lot of use cases I think. But I have no idea of the complexity!
+1
I have the same use case. My JWT token keeps expiring, I wish to have my request codeblock always fetch an access-token before making the request.
An idea I had was to have "named" requests defined somewhere, and reference the token-fetching request as a prev-request in the codeblocks where we want to chain the requests.
Hello @sajalverma17, @jbmerli,
I've been thinking about this, and I came up with the idea of using numbers to define requests — something like this:
```req
url-1: https://example.com
headers-1: {...}
body-1: something
url-2: https://two.example.com
```
What do you think? Do you have any other ideas on how we could implement this?
Hello @Rooyca,
Thank you for taking the time to look at that!
In your example, how do you retrieve the result of the first query (and pass it on to the second query)?
Hello @Rooyca,
Thank you for taking the time to look at that!
In your example, how do you retrieve the result of the first query (and pass it on to the second query)?
+1
That is what would make this usable for me. I suggest something like
url-prev: https://first.resource.com
headers-prev: {...}
body-prev: {...}
result-prev: $access_token_result:<JSONPath for access_token variable from result body>
url: https://two.example.com
headers: { authorization: $access_token_result}
Hello @sajalverma17, @jbmerli! 👋
I was looking into this and noticed that the feature was already built into the plugin—it was just a bug that was preventing it from working correctly. This should now be fixed, and it’s possible to reuse responses from other codeblocks, even across different files.
I’ve added an explanation in the documentation to clarify how it works.
I hope this update helps with your use cases! If not, please feel free to share any suggestions or improvements you’d like to see.
Thanks, and have a great day! 👍
Hello @Rooyca,
Sorry for the late reply!
And thank you for your answer!
I wanted to test the new functionnality, but now nothing works anymore :(
I suspect this is due to an Obsidian update..
Is your plugin still working? On my end, I'm getting 400 or 401 errors on the API I was calling before, and a log (on the server side) indicating “malformed JSON.”..
It's working for me. Have you try it with another api?
It's working with your link and GET requests I guess.
My query that is not currently working is a POST one:
url: https://backoffice.website.net/api/login_check
method: POST
body: {"username": "[email protected]", "password": "XXX"}
headers: {"Content-Type": "application/json"}
It looks like the body part isn't being sent correctly...
So weird, it works fine on my end. Could you please try with another post request? Maybe try uninstalling and re-installing...
I tried reinstalling the plugin, but it didn't change anything..
What's strange is that it works fine with curl:
curl -k -X POST -H "Content-Type: application/json" "https://backoffice.website.net/api/login_check" -d "{\"username\":\"[email protected]\",\"password\":\"XXX\"}"
I am trying to display the raw query with the dev tools, but the query is not displaying. I don't know what I'm missing!
Umm, you're right, it seems that something its broken. I'll take a look at it.
Never mind, I tested it again and it worked fine. Could you try this:
```req
url: https://reqres.in/api/users
method: post
body: {"name": "John Doe", "job": "Developer"}
headers: {"x-api-key: reqres-free-v1"}
```
Also, in your actual request could you try headers: {"Content-Type: application/json"} or even removing the header.
Your request works fine.
On my request, with headers: {"Content-Type: application/json"} I get: Error: Request failed, status 400.
Without the header, I get Error: Request failed, status 404 (which is probably ok).
It seems that something change with your endpoint. Could you try adding a User-Agent to your headers?
After debugging, we found that the body sent is not a JSON string. We corrected this by modifying this part of the plugin:
const response = await (0, import_obsidian3.requestUrl)({
url: URL,
method,
headers,
body
});
to:
const response = await (0, import_obsidian3.requestUrl)({
url: URL,
method,
headers,
body : JSON.stringify(body)
});
Your previous example:
url: https://reqres.in/api/users
method: post
body: {"name": "John Doe", "job": "Developer"}
headers: {"x-api-key: reqres-free-v1"}
did not show the problem because it returns the same result as without a body:
url: https://reqres.in/api/users
method: post
body:
headers: {"x-api-key: reqres-free-v1"}
You're right, RequestUrlParam. Thanks!
Thank you!
I may have another suggestion :)
I am trying to have a different request for each page with an API call that retrieves different content based on a page parameter. With the Obsidian cache system, when I switch from one page to another, the content displayed remains that of the first page opened. I tried ‘auto-update’, which improves things but not completely (I'm not sure how it works exactly, to be honest). In my case, it would be useful to be able to use a dynamic name for the data in local storage. Example: req-uuid: test-{{this.clientname}} Currently, it does not take the variable into account and creates a ‘test-’ key.
Anyway, thank you very much for your time!
The auto-update option attempts to update the request whenever possible. (https://rooyca.github.io/obsidian-api-request/en/codeblocks/#auto-update)
That sounds like a useful feature — I’ll work on adding it tomorrow.
Could you please open a new issue to track this?
Done (https://github.com/Rooyca/obsidian-api-request/issues/60).
Thank you very much!