Caching of API calls?

[Chris Lamb]

I am working on an external program using the API to do Check In / Check Out. I have successfully Checked Out assets as well as Checked them in. However, I noticed that there seems to be an issue with either caching information through the API or delayed updates. If I issue a PUT command to update the Checked Out user for an asset, the change is immediately reflected in the Sherpadesk web client (that's great, it's what it should do). If I then query this same Asset using the API in either my own program or Postman I do not see the updated data returned for at least 2 minutes. Is there some form of caching going on? The whole point of having an API is real-time access. We only allow assets to be checked out once. If it is checked out, you must check it back in again before you can check it out. If I have many people using the program simultaneously there is the possibility that someone could checkout a device to another person because the data retrieved through the API call shows the device as not checked out when in fact it was just checked out less than 2 minutes prior.

-Chris

[Justin Estruch]

I’ve noticed the same thing in my application. When I would do a put to update an asset and then request a get. The first result would sometimes come back extremely quick with the old asset info. Then after running the get a few times for the asset It would alternate between the new updated info and the old info. It seems like a caching issue to me since the results come back so fast compared to after about 5 mins I’ll run the get again and it takes about a second but the api will return the new updated info. Looks like a caching issue or maybe there is some sort of load balancing issue and the databases haven’t synced? Not sure.

[Lamb, Chris]

This is exactly what I am seeing. I recorded a video of me pressing "Send" in Postman without changing anything and the data changed back and forth between the old values and the new. Just trying to track down where it's happening. Never seen this before with any of the API's I have used.

-Chris

--


This email message, including any attachment(s), may contain confidential
and privileged information. It is for the sole use of the intended
recipient and  therefore, any unauthorized review, use, disclosure,
duplication or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies
of the original message.  Thank you.

 

--
You received this message because you are subscribed to a topic in the Google Groups "SherpaDesk API" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sherpadesk-api/IWq6Yut99gM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sherpadesk-ap...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sherpadesk-api/4ba77442-02ee-4b2b-8a34-c5f545ed6079%40googlegroups.com.

[chrisl...@gmail.com]

Justin,

Add a c=1 parameter to the end of your GET request. According to Eugene this avoids the cache.

-Chris

[jestr...@gmail.com]

Thanks Chris. I'm still noticing caching in my app. Has adding c=1 helped you? To be more specific my GET request is below:

'http://api.sherpadesk.com/assets?c=1&search=exampleAssetID'

Thanks,

Justin

[Lamb, Chris]

It did. Although it does take a few seconds before the old record changes to reflect the new. Better than it was. Am I wrong to think the API should be real-time? Idoesn’t appear to be that way. Looks like delayed writes on the DB.

Chris Lamb
CIO - Wylie Independent School District
951 S. Ballard Ave.
Wylie, TX 75098

On Aug 8, 2019, at 4:36 PM, "jestr...@gmail.com<mailto:jestr...@gmail.com>" <jestr...@gmail.com<mailto:jestr...@gmail.com>> wrote:

Thanks Chris. I'm still noticing caching in my app. Has adding c=1 helped you? To be more specific my GET request is below:

'http://api.sherpadesk.com/assets?c=1&search=exampleAssetID'

Thanks,
Justin

On Thursday, August 8, 2019 at 2:39:48 PM UTC-4, chris...@gmail.com<http://gmail.com> wrote:
Justin,

Add a c=1 parameter to the end of your GET request. According to Eugene this avoids the cache.

-Chris

On Wednesday, August 7, 2019 at 2:38:12 PM UTC-5, Justin Estruch wrote:
I’ve noticed the same thing in my application. When I would do a put to update an asset and then request a get. The first result would sometimes come back extremely quick with the old asset info. Then after running the get a few times for the asset It would alternate between the new updated info and the old info. It seems like a caching issue to me since the results come back so fast compared to after about 5 mins I’ll run the get again and it takes about a second but the api will return the new updated info. Looks like a caching issue or maybe there is some sort of load balancing issue and the databases haven’t synced? Not sure.

--
You received this message because you are subscribed to a topic in the Google Groups "SherpaDesk API" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sherpadesk-api/IWq6Yut99gM/unsubscribe.

To unsubscribe from this group and all its topics, send an email to sherpadesk-ap...@googlegroups.com<mailto:sherpadesk-ap...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/sherpadesk-api/782a666a-994d-467b-a7a2-5123d9d3caa1%40googlegroups.com<https://groups.google.com/d/msgid/sherpadesk-api/782a666a-994d-467b-a7a2-5123d9d3caa1%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Justin Estruch]

Looks to be working much better now. I never added "cache: false" to my ajax request. After adding it all is good now. I agree the DB should be real time, there's no point in reading old data. But I do understand that they want to protect themselves by adding caching and whatnot. But there's probably a better way to do so .Anyways thanks for your help Chris and Eugene!

On Thursday, August 8, 2019 at 5:40:47 PM UTC-4, Lamb, Chris wrote:

It did. Although it does take a few seconds before the old record changes to reflect the new. Better than it was. Am I wrong to think the API should be real-time? Idoesn’t appear to be that way. Looks like delayed writes on the DB.

Chris Lamb
CIO - Wylie Independent School District
951 S. Ballard Ave.
Wylie, TX 75098

Thanks Chris. I'm still noticing caching in my app. Has adding c=1 helped you? To be more specific my GET request is below:

'http://api.sherpadesk.com/assets?c=1&search=exampleAssetID'

Thanks,
Justin

On Thursday, August 8, 2019 at 2:39:48 PM UTC-4, chris...@gmail.com<http://gmail.com> wrote:
Justin,

Add a c=1 parameter to the end of your GET request. According to Eugene this avoids the cache.

-Chris

On Wednesday, August 7, 2019 at 2:38:12 PM UTC-5, Justin Estruch wrote:
I’ve noticed the same thing in my application. When I would do a put to update an asset and then request a get. The first result would sometimes come back extremely quick with the old asset info. Then after running the get a few times for the asset It would alternate between the new updated info and the old info. It seems like a caching issue to me since the results come back so fast compared to after about 5 mins I’ll run the get again and it takes about a second but the api will return the new updated info. Looks like a caching issue or maybe there is some sort of load balancing issue and the databases haven’t synced? Not sure.

--
You received this message because you are subscribed to a topic in the Google Groups "SherpaDesk API" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sherpadesk-api/IWq6Yut99gM/unsubscribe.

To unsubscribe from this group and all its topics, send an email to sherpad...@googlegroups.com<mailto:sherpadesk-api+unsubscribe@googlegroups.com>.