[API][v3] Query Types by sub-category [opgelost]

Hello,

I've started working with the API and would like to request the ability to search types by sub-category (ex: “Standard circulation coins” and/or “Circulating commemorative coins”).

For example, right now I can do:

/types?lang=en&category=coin&issuer=canada

But that comes back with a response that there are 3687 matching types, and the info in the result set only shows me “category: coin” so I can't filter further before requesting each type's detailed information.

Based on searching through the website, I know that limiting my search to the sub-categories of coins I'm interested in brings that down to a much more reasonable 330 types for Canada. 

I'd rather not have to burn through 75 queries (to grab those 3687 types 50-at-a-time), then burn through another 3,687 queries to loop through all of them for the detailed information, just to discard 91% of the results because I'm not interested in them. That's a lot of unnecessary queries! And that's just for one issuer. 

It would be great if, like the website, you could specify that you wanted not just category=coin, but also sub-categories like “Standard Circulation Coins” and “Circulating Commemorative Coins”. 

Because honestly, those are the only two coin types I'm interested in, but I'm interested in those types from several dozen countries.

That would let me do something like this: 

/types?lang=en&category=coin&subcategory=1-2&issuer=canada

(I took the “1-2” from the st= parameter on the regular website when I search those types)

Then I could loop through the results in 7 passes of 50 each, and grab the details in another 330 passes and move onto Australia, or the UK, or whichever country is next in my list. That would be 337 queries bringing back 100% useful results instead of 3,672 queries bringing back 9% useful results.

If there's already a reliable way to do this, please let me know!

Cheers,

Jon

Yes, that would be an improvement to this endpoint. Also expanding the responses to more than 50, maybe 100.
 

Wouldn't it also help you if one of the response field is the last update timestamp? This way you would avoid re-downloading detailed data that you already have, and save most of the API calls.

Ooh, that's a great idea. Last update would absolutely save on re-queries! Hopefully that's info that's available on the back end. 

So what's the best way to make sure this gets seen by the right folks? Is there someone we should “@” who is the API guy? Or do these suggestions go into a review queue automatically? (Or maybe they monitor the forums?)

If there's anything I can do to help, I'd love to know. I'm a career IT Sysadmin with more hours than I can count on both the DBA side (SQL Server, Oracle, dabbled in postgres), and several programming and scripting languages under my belt. So if I can contribute my skills in any way to help make Numista's API better let me know!

Cryovenom

 Is there someone we should “@” who is the API guy? 

@Xavier 

Still wondering if this has gotten any traction… I've basically held off using the API as it is because I would just be blasting the server with thousands of queries whose results I don't care about just to find the needles in the haystack.

I found this thread after sending a DM to @Xavier as well. I think that ideally the detailed type ("standard-issue", “merchant-token”, “pattern”) etc, should be included in the response to the ‘GET:/issues’ endpoint array of results, in addition to allowing filtering by those detailed types rather than just “coin” or “exonumia”. 

I'm not sure if this change would necessitate a major version bump in the API though - depending on what versioning scheme was chosen, it may be the kind of thing that makes a “v3.1”.

Well that was quick!

Looks like the change has already been made to the API, with both of my suggestions! I really appreciate both the work and the speed!

I've confirmed it works as well, by sourcing the codes from the search page on the website I'm able to filter by object type at an advanced level.

I've slowly been building the list of types now, but there are quite a few :)

Sweet! Thanks usepgp for bringing attention back to the request, and thanks Xavier / dzmitry.huletski for making the change! :)

I'll have to dig back into my coin collection project again now that this is available.

Cheers!

Hi,

Sorry we missed to communicate properly. I confirm it's now possible to filter by object type of subtype and the subtype is returned in the API responses.