non erat sem Proprietary + Confidential Our own format... While Tony Tam was creating Swagger... In 2010, Google APIs team launched infrastructure based on the Discovery Format -- a JSON format
non erat sem Proprietary + Confidential A substantial amount of infrastructure was written based on it: Some visible • Client library generation (10 languages) • APIs Explorer • Discovery service • Documentation generation Some not visible • Proxy (translates JSON over HTTP to proto over stubby), capable of X million requests per second Discovery Document
non erat sem Proprietary + Confidential What went well... • Over 150 public APIs • Hundreds of thousands of developers • Many, many billions of API calls...every day. What didn’t go so well... • Didn’t work with the open source community Post Mortem
non erat sem Proprietary + Confidential Our own format (cont’d)... In 2015, in response to a need for lower latency, more efficient data, and HTTP/2 features like bi-directional streaming, we introduced gRPC. But...all done in open source this time!
non erat sem Proprietary + Confidential Kubernetes Kubernetes is an open source container management system, initially released in 2014. Kubernetes.io publishes all APIs in Swagger (currently 1.2, will upgrade to publish v2.0 as of kubernetes 1.5). Kubernetes server publishes Swagger specs and ships with Swagger UI
non erat sem Proprietary + Confidential Google’s gRPC APIs are Serving OpenAPI specs One of the features of our new API infrastructure is serving multiple description formats...including OpenAPI specs. https://cloudfunctions.googleapis.com/$discovery/swagger2?version=v1
non erat sem Proprietary + Confidential Google API Compiler Open source compiler that takes OAS files (or .proto + YAML) and generates Google API Service Configurations Service Config is used by various downstream systems (client library generation, documentation gen, etc). Open sourced here, more tools to come.
non erat sem Proprietary + Confidential • API Management from Google • This architecture serves hundreds of billions of requests per day • All configuration happens through Open API spec or via GRPC Cloud Endpoints
non erat sem Proprietary + Confidential JSON-HTTP/1.1 Use Open API specs to manage RESTful APIs written in any language and with any framework. proto-HTTP/2 Use gRPC to build highly efficient HTTP/2-based APIs Cloud Endpoints: Choose your protocol
non erat sem Proprietary + Confidential $ ls package.json high-score.js high-score-open-api.yaml app.yaml $ gcloud app deploy Recognized a [node] application Recognized an [OpenAPI] API spec Building app image… done Deploying app image to [http://high-score.stannrapis.com]… done Now serving API at [http://high-score.stannrapis.com]… done Manage the API at [console.developers.google.com] $ curl high-score.stannrapis.com/v1/scores/0 { “highscores”: [ {“score”:125239, “player”:“dwc”}, {“score”:124231, “player”:“jta”} ] } 1. System detects an Open API spec (yaml) with app 2. Does normal App Engine Flex app package & deploy 3. Spins up additional proxy container with GAE container, applies control plane 4. API is served, listed in Cloud Console user interface
non erat sem Proprietary + Confidential APIs are...big at Google Open Source • Both Apigee and Google were founding members of the Open API Initiative • We will undoubtedly continue to work both with the spec and with various open source projects related to it • Google Cloud is committed to being the open cloud -- contributing to existing products, open sourcing internal technologies, creating new projects
non erat sem Proprietary + Confidential How do you represent a more RPC-style API in the spec? How about proto? Could there be a canonical representation of a gRPC API in Open API? Can our experience with code gen be useful? Can we represent the richness of the Discovery Document in Open API? Issues important to us