data.lotro.com Questions

[CptBoeing]

Hi,

I have some questions about data.lotro.com usage mostly regarding access restrictions and error codes.

1) It was stated that we should not request the same information more than once in a 24h period. This was stated on some old pages in one of the developer's "my.lotro.com" page. Now, we have the "cachedUntil" information. So, we should respect the cached until and only request information after that time, or we should only request information once each 24h regardless of the "cachedUntil" information?

2) Is it possible to get some infomation on the error codes we get from the API? Like "noCharacter" and "ItemFetchError" and other errors? Would be interesting to know what they mean so we can properly handle them on our applications.

Thank you very much and the API is great for many things.

[Duwis]

1) It was stated that we should not request the same information more than once in a 24h period. This was stated on some old pages in one of the developer's "my.lotro.com" page. Now, we have the "cachedUntil" information. So, we should respect the cached until and only request information after that time, or we should only request information once each 24h regardless of the "cachedUntil" information?

We don't have a hard rule on this; we give you the cachedUntil information as a guide for when you can reasonably expect the potential for the information to change. For items, it is unlikely that its data will change even if the cachedUntil date expires. Item data usually changes around the time of releases, patches, etc.

However, character sheets and kinship rosters can be more fluid. For these, it would be reasonable to check the data once a day or a reasonable time on or after the cachedUntil time.

Basically, if you don't flood us with requests, we won't shut you down.

2) Is it possible to get some infomation on the error codes we get from the API? Like "noCharacter" and "ItemFetchError" and other errors? Would be interesting to know what they mean so we can properly handle them on our applications.

Thank you very much and the API is great for many things.

Not really much more information beyond that to give. You'll either get back the data or an error code indicating something prevented us from generating that data.

[CptBoeing]

For item data I actually cache it for 30 days, but might as well cache it indefinitely with a possibility to override it and re-fetch after patches and such.

For character and kinship data, I was expecting to be able to fetch it 2 or 3 times a day. But if the site grows too much, that would mean a lot of request on a daily basis. Since I am mostly interested on keeping history of level advancement, I may have a rule which refreshes character data based on level. Lower levels refresh more often than higher levels, since they are more likely to level twice a day.

As for the error codes, I was hoping to know for example the chances of possible recovery. For example:
"noCharacter" means the character does not exist or simply that it is outdated? If it does not exist, there is no point trying to sync him again in the near future, if it is outdated, I can keep it in the regular update schedule and eventually get some information.
Right now I think it is the former case, the character was deleted. So I can handle it and prune the character from my database.
The same goes for the item error codes, I would like a hint on wether some error codes are recoverable (I can hope to get information in the future) or not.

Thanks.

[Duwis]

For item data I actually cache it for 30 days, but might as well cache it indefinitely with a possibility to override it and re-fetch after patches and such.

You don't necessarily have to cache it indefinitely, but it is something that could be queried more on the order of once a week.

For character and kinship data, I was expecting to be able to fetch it 2 or 3 times a day.

That would likely be acceptable; two or three requests per client a day is not unreasonable. Again, we're only concerned if a client is spamming requests unreasonably. i.e., the extreme example would be turning on the app and having it send out a request every minute.

As for the error codes, I was hoping to know for example the chances of possible recovery.

That's certainly something we can think about building into a future revision of the API. For characters, we could return a more specific 'deleted' error code when we know the character has been deleted.

[CptBoeing]

That would likely be acceptable; two or three requests per client a day is not unreasonable. Again, we're only concerned if a client is spamming requests unreasonably. i.e., the extreme example would be turning on the app and having it send out a request every minute.

Actually, it would generate 2 or 3 requests per day for each character in my database. The total requests is really going to be dependent on the number of people that uses the application. So I guess I will worry about that later.

That's certainly something we can think about building into a future revision of the API. For characters, we could return a more specific 'deleted' error code when we know the character has been deleted.

That would be really helpful, so I could prune deleted items and characters from my database, or at least, never request an update for them.

Thank you for the answers.