Closed htj closed 8 years ago
@htj apologies for the inconvenience. This will be fixed in release 2.0.6 which is slated for deployment tomorrow or the day after. @vegu is working towards providing an /ix?net=YY
and /ix?net__asn=XX
endpoint.
@htj did you see http://lists.peeringdb.com/pipermail/pdb-announce/2016-March/000046.html ? Depending on your use case you now only need one or two queries.
ix name is still not included in the search results for network.
Yeah, I can do https://www.peeringdb.com/api/ix?net__asn=xxx, but it still requires me to do two API calls, as I need the macro, prefix limit, description etc. when setting up a peer.
It should not be necessary to make multiple queries for this. It really really should not.
It is one of the most basic (if not the most) API functionality in peeringdb? I'm setting up a peering with this network, I give peeringdb an as number, PeeringDB gives me as-macro, prefix limit, description, and a list of IX names and IP addresses at each IX. This should be one call.
The style of protocol design PeeringDB is currently doing was quite prevalent 10-15 years ago (often implemented with SOAP, and coupled with a query function that was a bad wrapper around SQL), where the resulting objects was very closely modelled to the schema. However it turns out that people are very rarely interested in the underlying schema, and that any form of schema migration becomes a complete pain. Furthermore the design is typically inefficient as it requires multiple calls, which causes bigger server load, and creates more client complexity. However this practice was mostly abandoned along with the switch to HTTP APIs, where the focus was to provide simpler and easier to use APIs targeted towards common use cases.
Good feedback, we'll improve the API further.
Added more fields, let us know if you're missing any others.
The "style" of PeeringDB is to be as compatible as possible with all the legacy applications written to download the full database and use static IDs to operate on data. Since there was never anything but sync in version 1, we focused on that. You can sync the entire database in a few calls, and do only incremental changes after that.
Now that version 2 is out, we'll be trying to make the RESTful API more user friendly.
Also worth noting, anything written for automation purposes should use a local copy anyways, otherwise our operations could interfere with your operational tasks.
This works now.
We can always input stuff manually, so it isn't a deal breaker for us. I doubt most people will use a local copy.
See #69 for original request and #86 which broke our system :-/
https://www.peeringdb.com/api/net?asn=2603&depth=4"
Does not include IX names. It does not show anything more than depth=2
I still cannot fathom why getting the IX names for a network has to be an exotic thing.