This idea was imported from Canny. Originally created by: Zachary Smith. The current owner is: Unassigned.
Introduce a new endpoint (example: /locations), that will have a more robust way to showcase locations of infrastructure and services in the Metal Platform. Suggestion is to introduce a new endpoint that supports:
1. Facility - Similar to https://www.packet.com/developers/api/facilities/
2. Metro (AZ) - One or more facilities that share local network reachability and routing
3. Region - Collection of Metros
4. Geography - One or more Region that takes into account jurisdictional boundaris
With our expanded support for multiple facilities within a Metro, customers should have the ability (and perhaps be restricted to) deploying at the Metro layer and above.
This comment was imported from Canny. Originally created by: Bob Fraser with 0 likes.
The first installment of the Locations concept - Metros is now live: https://feedback.equinixmetal.com/changelog/new-metros-feature-live
This comment was imported from Canny. Originally created by: Jake Warner with 0 likes.
Being able to see which facilities are in which countries / continents / regions would be incredibly helpful.
This comment was imported from Canny. Originally created by: Zachary Smith with 0 likes.
We're hard at work on our new /locations endpoint. More details to come soon!
This comment was imported from Canny. Originally created by: Matt Anderson with 0 likes.
Similar to Marques Johansson comment, when we introduce the coupling of infrastructure + services in conjunction with geography we should pretty immediately be introducing an output of what resources and restrictions would be in the respective geographical facilities and/or regions. Future feature development may be highly caveated as to what scope we release it at (e.g. feature that is facility level vs. region level varies based on complexity)
This comment was imported from Canny. Originally created by: Marques Johansson with 8 likes.
Our facilities have a feature matrix and plan capacity that distinguishes one facility from another. What distinguishing features could one expect from Region and Geography levels? How do these levels affect transfer, address space, storage attachment, DNS, privacy (GDPR), other professional or government or regulatory standards, and the feature matrix between the different boundary levels. Going in the opposite direction, I've learned that some Packet product features are limited in functionality by the rack (nuanced layer2 and multicast features work differently within the same rack). "locations" could be "geos". Our API's current "include" feature makes the following possible. I'm not necessarily advocating for this, just considering it is possible. I'm sure the pluralizations are wrong. GET /geo?include=regions,regions.metros,regions.metros.facilities GET /geo/na?include=regions,regions.metros,regions.metros.facilities GET /geo/na/region/us-southeast?include=metros,metros.facilities GET /geo/na/region/us-southeast/metro/atl?include=facilities The canonical URL for each facility to map back to our existing facility resources, or we could go the other way and make /geo endpoints the canonical representation. Does the Equinix API already have a similar model? Could these resources and distinctions be best defined within those APIs? For example, I may want to know which IBXs in Europe support both Fabric and Metal+Storage are available.
This comment was imported from Canny. Originally created by: Nathan Goulding with 7 likes.
+1000