search

peeringdb / docs

docs.peeringdb.com site
https://docs.peeringdb.com/
25 stars 30 forks source link

Depth expand doesn't work for api/net?asn=... #89

Closed htj closed 8 years ago

htj commented 8 years ago

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.

job commented 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=XXendpoint.

job commented 8 years ago

@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.

htj commented 8 years ago

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.

job commented 8 years ago

Good feedback, we'll improve the API further.

grizz commented 8 years ago

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.

htj commented 8 years ago

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.