This goes against HTTP but I envision caching being useful in some situations (e.g. request is a function for a search, request body contains search params) . Is it a good pattern while designing APIs ?
~~ Q : Source : Slack ~~
Solved! Go to Solution.
I would still not cache it (even when searching). In the example you are talking about, I would expect a call like this:
POST /api/search
This should return a "search id" in addition to the result set. If the user wants to search with the same criteria, then I'd expect the user to send:
GET /api/search/{id}
Hi Anil,
Considering the scenario, you have posted the (request is a function for a search, request body contains search params), extract the unique parameter in the requet like bankAccountNumber, userId, phoneNumber etc. Make that parameter as Key and populate the response to the cache. When we call the API again, we can fetch the details from cache using the same API key.
I would still not cache it (even when searching). In the example you are talking about, I would expect a call like this:
POST /api/search
This should return a "search id" in addition to the result set. If the user wants to search with the same criteria, then I'd expect the user to send:
GET /api/search/{id}
Let us consider a scenario. There is an post API search. In the request we can send either id or userName.
POST /api/search
Request : {"id" : "abcd"} or { "userName" : "xyz"}.
When id/userName comes in the request. we can extract that id/userName and assign it some variable say cacheKey and while populating the response to cache we can use this cacheKey as a KeyFragment.
In lookup we can use the same cacheKey and retrieve the response from cache