[FEATURE REQUEST] API Query Search Enh.
alkaniserval.5963:
To whom it may concern:
Would it be possible to add in the following enhancements to recipe:search :
Search by Profession (i.e. Armorsmith, Weaponsmith, &c)
Envisioned as: http://api.guildwars2.com/v2/recipes?discipline=DISCIPLINE
Search by Type (i.e. Axe, Bag, &c)
Envisioned as http://api.guildwars2.com/v2/recipies?type=TYPE
Search by Profession Skill Tier (i.e. Novice, Adept, &c)
Envision as http://api.guildwars2.com/v2/recipies?tier=TIER
NOTE: This could simply be an alias to a query that knows to look for the floor and ceiling values of the Tier range. The back-end query, assuming an RDB, would be something along the lines of
SELECT PARAMETERS FROM DATABASE DATABASE WHERE min-range BETWEEN TIERSTART AND TIEREND
Multiple Constraint Returns (i.e. Search by Profession AND Tier)
Envision as http://api.guildwars2.com/v2/recipes?profession=PROFESSION&tier=TIER
Add Name as a field in Recipe Information
This reduces the number of client cross queries that have to be made. If using a RDB, then this could also be programmed as a view presented via the API. At the moment, I must make a query to recipe, then make a query to items and compare on items.
Eventually, it would be nice to fully implement the recipe:search function to be able to search on any of the multiple fields present within each recipe record. In lieu of that, however, this is probably the bare minimum needed to allow for end-users to retrieve specific datasets without having to gather ALL of the data at one and then sort through it manually.
Technically, some of these queries already exist in game. In essence, what I am asking is that the API provide some of the in-game sorting and querying functionality via the JSON Query Interface for consistency (and also so that API end-users don’t have to use brute-force when doing initial builds and retrieves of specific data sets).
If you have any questions, please contact me via whisper in-game.
Thank you!
Strategist.6132:
I think it would be nice to have, but I wouldn’t put it as a priority. I mean right now you can easily mimic what that API is supposed to do. AKA:
- Pull all items to your own server (using the /v2/items/ API)
- Make your own search API. (Which shouldn’t be that hard I guess)
- Let users or your own site/app/program use that API.
I guess this also relieves some stress of the GW2 API servers. Even though I don’t think the idea’s you provided would be that heavy to implement/run. But for example a /v2/recipies?name= operation, where you search for recipes with a word in the title of the recipe, would quickly get spammed by autocomplete functions of developers and wouldn’t be a good idea.
The idea is nice! But not really neccecary right now I think.
Pat Cavit.9234:
We’re going to do some experiments around searching to see if we can’t start offering richer search APIs in the future. Can’t promise anything though.
alkaniserval.5963:
We’re going to do some experiments around searching to see if we can’t start offering richer search APIs in the future. Can’t promise anything though.
Pat,
I definitely appreciate you guys considering it. My hope is that simplified searches will help reduce the overall number of queries, application processing, and network traffic required for someone to get a set piece of information. I know you all have a lot on your plate and there may not be adequate demand for these, but seeing as some of the in-game browsing also uses, or at least seems to use based on the APIs, HTTPS for communications (and likely processes the information gathered from these same JSON queries) this might be helpful in the long run as a slow-burner project.
If there’s anything I can do to assist, please feel free to reach out to me either in-game or via message here.
Thank you!
alkaniserval.5963:
I think it would be nice to have, but I wouldn’t put it as a priority.
No, this is definitely not a high priority; most feature enhancements are intended to be nice little things for software developers to consider adding to their code. If it was a problem, I should be filing a bug report instead of making a suggestion for a new API extension.
I mean right now you can easily mimic what that API is supposed to do. AKA:
- Pull all items to your own server (using the /v2/items/ API)
- Make your own search API. (Which shouldn’t be that hard I guess)
- Let users or your own site/app/program use that API.
Yes, I could reinvent the wheel as many other people have; I could even consider using one of the other APIs that people have implemented; however, if enough people implement the same function when doing the basic data grab, before their application has even had a chance to actually do something with the data, what that says is that the API users may be better served by having ArenaNet implement that basic functionality into their API. That’s one of the reasons I’m making the suggestion.
I guess this also relieves some stress of the GW2 API servers.
It can, depending on whether they’re also utilizing their own API servers in-game. The bandwidth savings could be quite substantial all for having a dedicated search function that handles specific, repeatedly-used requests. That’s something for them to determine in-house to see if there is a benefit for rather than for us to speculate on, however. This function can, in theory, also be extended to or borrowed from the Black Lion Trading Post.
Even though I don’t think the idea’s you provided would be that heavy to implement/run.
No, performing the initial query may not be so bad, but performing subsequent recursive queries only to throw away the data is, especially if your application updates that single dataset frequently. It’s wasteful of both a site’s and ArenaNet’s bandwidth if they don’t want all of the data.
But for example a /v2/recipies?name= operation, where you search for recipes with a word in the title of the recipe, would quickly get spammed by autocomplete functions of developers and wouldn’t be a good idea.
Because someone can’t implement that now if they were so inclined? If there is a concern about constant queries from external, non ArenaNet sources, my guess is they’re addressing it. And if not, they might be soon. Who knows for sure?
The idea is nice! But not really neccecary right now I think.
Thank you, and I agree; this feature isn’t something that needs to be implemented right this very moment. I expect that if Pat Cavit and his team take this on, this will be a slow burning project released over the next year or two, if that. I have no idea how many developers they have and with Heart of Thorns coming out in a few months, plus other balance and bug fixes, they have their hands pretty full. This is definitely a “would be nice to have” and I’m not holding my breath waiting for it.
Thank you!
Alpha.6913:
To whom it may concern:
Would it be possible to add in the following enhancements to recipe:search :
Search by Profession (i.e. Armorsmith, Weaponsmith, &c)
Envisioned as: http://api.guildwars2.com/v2/recipes?discipline=DISCIPLINESearch by Type (i.e. Axe, Bag, &c)
Envisioned as http://api.guildwars2.com/v2/recipies?type=TYPESearch by Profession Skill Tier (i.e. Novice, Adept, &c)
Envision as http://api.guildwars2.com/v2/recipies?tier=TIER
NOTE: This could simply be an alias to a query that knows to look for the floor and ceiling values of the Tier range. The back-end query, assuming an RDB, would be something along the lines of
SELECT PARAMETERS FROM DATABASE DATABASE WHERE min-range BETWEEN TIERSTART AND TIERENDMultiple Constraint Returns (i.e. Search by Profession AND Tier)
Envision as http://api.guildwars2.com/v2/recipes?profession=PROFESSION&tier=TIERAdd Name as a field in Recipe Information
This reduces the number of client cross queries that have to be made. If using a RDB, then this could also be programmed as a view presented via the API. At the moment, I must make a query to recipe, then make a query to items and compare on items.Eventually, it would be nice to fully implement the recipe:search function to be able to search on any of the multiple fields present within each recipe record. In lieu of that, however, this is probably the bare minimum needed to allow for end-users to retrieve specific datasets without having to gather ALL of the data at one and then sort through it manually.
Technically, some of these queries already exist in game. In essence, what I am asking is that the API provide some of the in-game sorting and querying functionality via the JSON Query Interface for consistency (and also so that API end-users don’t have to use brute-force when doing initial builds and retrieves of specific data sets).
If you have any questions, please contact me via whisper in-game.
Thank you!
Search by Type (i.e. Axe, Bag, &c)
Envisioned as http://api.guildwars2.com/v2/recipies?type=TYPE
…
Why dont you get all game items through theyr json and insert them in your database? By all items i mean all 40k items more or less. Sorting and any criteria you wanna apply is faster through getting them from your database.
alkaniserval.5963:
Why dont you get all game items through theyr json and insert them in your database? By all items i mean all 40k items more or less. Sorting and any criteria you wanna apply is faster through getting them from your database.
I already know what I can do to resolve this problem, but that’s not the point of a Feature Enhancement Request.
The point of a feature request is to ask a developer if they would be willing to enhance their product to provide additional functionality. It’s not a demand, it’s an inquiry.
Also, I’m not interested in sorting through items, I’m interested in enhancing the recipe search functionality.