Api Caching
stress level zero.4907:
Looking at the response headers there isn’t any cache headers specified (looking at the item/skin apis).
Is there any reason for this? Didn’t want to worry about cache invalidation?
Cheers,
Michael
Lawton Campbell.8517:
Seems like an oversight on my part; I can’t think of any reason we shouldn’t put the per-endpoint cache expiries in there. Would make it more explicit (and data-driven) how frequently the endpoints can be polled in a useful manner (e.g., /v2/commerce/listings updates once/minute, whereas /v2/characters updates once/5 minutes).
stress level zero.4907:
Fair enough. Would make sense to add it!
On that note, re: the character api. With the character rendering api being on ArenaNets bucket list, is it actually within the realm of possibility any time soon (next few months)?
As well as, what are the chances of adding what current specializations/talents a character has to the character api?
Lawton Campbell.8517:
On that note, re: the character api. With the character rendering api being on ArenaNets bucket list, is it actually within the realm of possibility any time soon (next few months)?
Safe answer is no. I’m not too savvy about graphics stuff, but from my understanding the engine can’t do any software rasterizing — it needs an actual render context — which in Windows I guess means running as an application rather than a service. The render service currently runs as a windows service.
So before we can get pretty character renders we need to either integrate a software rasterizer into the engine or figure out how to deploy the render stuff wildly differently from all our other backend services. I don’t personally have the technical chops to do either of these in a timely fashion, so it’s a bit tricky to tell when it’ll be workable.
As well as, what are the chances of adding what current specializations/talents a character has to the character api?
This is a fairly high priority on my todo list; I think I can have it ready for the patch after the next patch (but no promises; I haven’t figured out where that data’s stored yet).
Valento.9852:
That would be the most awesome thing in this lovely API, though!
stress level zero.4907:
.. so it’s a bit tricky to tell when it’ll be workable.
Any chance for updating the character api to include details such as height, face details, skin colour, clothing colour, etc? Perhaps if we had easy access to this data someone in the community could try and hack something together with the client.
This is a fairly high priority on my todo list; I think I can have it ready for the patch after the next patch (but no promises; I haven’t figured out where that data’s stored yet).
Lovely.
How big is the api team? Just yourself? You’re doing a good job thanks for the hasty responses.
Lawton Campbell.8517:
Any chance for updating the character api to include details such as height, face details, skin colour, clothing colour, etc? Perhaps if we had easy access to this data someone in the community could try and hack something together with the client.
It’s possible, but I’m not sure how we’d expose the different faces/hairstyles/etc. Only sane way would be to dump the raw assets, but that’s kind of a mess of an approach that I’d like to avoid.
stress level zero.4907:
Alright no problem.
Any chance of a post being made of your current api road map for the next few months?
Lawton Campbell.8517:
Alright no problem.
Any chance of a post being made of your current api road map for the next few months?
We’re mostly using the api-cdi github repo (specifically, the issues for bugs and pull requests for proposed features). I typically tag things with “ready”, “in progress”, “needs deploy” etc to indicate what roughly is being worked on; these can be viewed on a kanban board with waffle.io.
The APIs nearest to ready (aside from /v2/traits, which is currently in beta) are probably the account skin/dye unlocks (which I haven’t drafted a PR for yet — I’m terrible). We’re a bit snagged internally due to a reworking of how scopes work.
rodadams.5963:
I don’t see wallet contents anywhere on your board.
This makes quaggan sad.
Lawton Campbell.8517:
I don’t see wallet contents anywhere on your board.
This makes quaggan sad.
I’ll draft it tomorrow.
I also need to write up pull requests for skin and dye unlocks.
Nabrok.9023:
Alright no problem.
Any chance of a post being made of your current api road map for the next few months?
We’re mostly using the api-cdi github repo (specifically, the issues for bugs and pull requests for proposed features). I typically tag things with “ready”, “in progress”, “needs deploy” etc to indicate what roughly is being worked on; these can be viewed on a kanban board with waffle.io.
The APIs nearest to ready (aside from /v2/traits, which is currently in beta) are probably the account skin/dye unlocks (which I haven’t drafted a PR for yet — I’m terrible). We’re a bit snagged internally due to a reworking of how scopes work.
In a previous post you mentioned the WvW endpoints might get an upgrade soon, is that still the case?
smiley.1438:
I guess WvW endpoints won’t be updated before HoT release, just to save up double work due to a major change (new borderland map).
Lawton Campbell.8517:
The wvw objectives endpoint needs changes made to content before it can be deployed — all of the objectives on the green/blue borderlands currently point to the lake.
I’ve only done a bit of work on the matches endpoint; need to spend some more time on it.
smiley.1438:
The wvw objectives endpoint needs changes made to content before it can be deployed — all of the objectives on the green/blue borderlands currently point to the lake.
Speaking of the underlying content: there are several problems i found while collecting the floor data – ok to open an issue on GitHub?
Lawton Campbell.8517:
The wvw objectives endpoint needs changes made to content before it can be deployed — all of the objectives on the green/blue borderlands currently point to the lake.
Speaking of the underlying content: there are several problems i found while collecting the floor data – ok to open an issue on GitHub?
Yeah, definitely. Tracking issues on GitHub is way easier than doing it on the forums <3