It absolutely is already a timeseries in the database. I just have not made proper timeseries endpoints for each of the possible use cases yet. That is actually still on the planned features list:
More statistical oriented views and information for all timeseries data (Shop Prices and World Polling currently)
Right now you can create graphs by the hour of player counts, beacon counts, plot counts and total prestige since those are inside of the main world poll data. I just have not had anyone interested in enough making those so I have not prioritized it.
I added another timeseries endpoint to specifically pull resource counts. I also added and updated the docs on the time filter for the Timeseries endpoints as well.
WARNING to anyone that uses the APIs at the moment. I am making some breaking changes to the Item Colors API views to clean them up a bit. I have decided not to create a whole new v2 schema for this because it is inline with how I originally envision the endpoint to be anyways.
The Item Colors endpoint (example for Meta: https://api.boundlexx.app/api/v1/items/10794/colors/?format=api) will only return a de-duped list of color and exist_on_perm. All other fields will be removed and there will no longer be multiple entries for each world/color combination, only a single one for that given color.
These changes will go live as soon as I get with my testing for the beginning of the Shop Prices APIs (only supported in Testing universe at the moment due to API Key limitations). This will likely be a few days at least, so if you will be affected by these changes, please update now. The changes are already live on the Testing universe API you can check them out if you want:
No, that requires actually rendering block models and stuff where is something I have not even gotten close to getting into. The Colors API does give you the base hex color values for each color though so it gives you a pretty close approximation of the in-game color.
Adds Shop Prices for Items to the Items and Worlds APIs; only available for the Testing Universe at the moment, do not have an API key for Live Universe yet. Live Universe Endpoints will always return no data for now. Still love to hear feedback on the new endpoints though!
More filters!
Items API can now be filtered with is_resource and has_colors
Worlds API can accept show_inactive to reveal worlds that are no longer returned by the Boundless Game API (expired Exos)
All of the block color endpoints can now take show_inactive_colors to show previously available colors for Sovereign worlds.
Good news everyone! (and bad news for some maybe?)
I have moved the āfront doorā of Boundlexx from Cloudflareās free tier to Microsoft Azure. I have some free credits floating around that allows me to get premium caching features for no cost. What this brings is significantly better caching. Cached responses will be much faster (usually 25x faster response time on average) and causing significantly less load on the origin server.
I am also dynamically purging the cache as well so URLs will stay fresh when they change. In other worlds, if a new Exoworld appears, I tell the CDN to throw out the cache on /api/v1/worlds/ so the new Exoworld will appear next time someone requests it. That means people are not waiting for 30 minutes+ for cached URLs to expire. However, it does take some time to purge cached URLs. It can take up to 2 minutes for a URL to be purged. So that means up to 2 minutes after an Exoworld is discovered, it may not appear on /api/v1/worlds/.
Also, formats. With caching, you must now be explicit about your format you want now. Before the API could guess pretty easily if you wanted the browsable API or a JSON response based on if your request was coming from a browser or code. With the caching in place now, that is not really possible, so you will need to be explicit about which format you want. Adding the query string parameter of format=api will force the browsable API and format=json will force a raw JSON response.
EDIT: You asked and I listened. Based on popular demand, format=json is the default 100% of the time now. If you want the browsable API, you much add format=api to the URL to get it.
These can kind of all be breaking changes so as a result, none of this is being forced on people right now. However the old Cloudflare routes are now deprecated. Please update your base URL for everything from https://boundlexx.app/api/v1/ to https://api.boundlexx.app/api/v1/ as soon as you are able to test the new caching changes and start using the format query param. https://boundlexx.app/api/v1/ will stay available for at least 1 week (through 9/20). After that date, I cannot promise it will keep working.
If you are having any trouble migrating or any problems with the new caching, please let me know.
Also checked out Metabase, pretty cool to see such graphs. Next week Iāll be exploring your Shop API options in the test universe. Your API has been very pleasant to use so far
Metabase is in your local timezone. It is auto-localized (I believe).
The API is provides datetimes in ISO 8601 format, but it is automatically converted to my local timezone (mostly for the admin site, it is just a built in feature of Django Rest Framework).
If you are using Python, you can convert the datetimes from the API using fromisoformat and then localize it with astimezone.
If you are using Javascript, you can convert datetimes from the API using Date.parse. I believe it is automatically localized to your browsers locales.
Yeah, I have no problems with the converting. But the metabase graphs Iām pretty sure is not my local time. @Bethlehem hunts are 8PM (peaks in graph) and they are 4PM for me. Iām +3 UTC, it would have to be 11 PM if it was local. Well local as in who is viewing in browser local.
Iāve been trying extremely hard to cache things for at least an hour locally before requesting new data. Do you have any rate limits you prefer people to keep to?
No. I do not plan to implement rate limits unless absolutely necessary. Rate limits are really hard to enforce unless you are authenticated (IPs are not considered 100% unique).
Because the data is relative static (no complex data that morphs based on user session), caching on the CDN side is relatively straightforward. So that being said, you should need to worry about caching or API performance from your side. If you are seeing performance problems (long response times, etc.), please let me know and I can help you troubleshoot what is going on.
Just because a lot of the data on my side is cached, that does not mean you can be wasteful. You should attempt to only get data only when necessary as that will improve user experience inside of whatever app you are building. If you are unsure how often an endpoint updates, feel free to ask. Hopefully a lot of the endpoints are pretty obvious. /api/v1/items basically never changes. /api/v1/worlds should only change when a new Sovereign or Exo world appears. World Polls changes every ~10 minutes. The Shop endpoints will have timestamps when they will update since those are a bit unpredictable.
