Previously, you set up Gloo Mesh Gateway, the portal server, and several sample apps. In this tutorial, you bundle your apps into API products that you later expose in a frontend developer portal.

Before you begin

Complete the portal setup tutorial.

Verify your ApiDocs

With Gloo Portal, you can share REST API services that conform to the OpenAPI specification (OAS), v2 or v3. Gloo uses an ApiDoc custom resource to identify the OpenAPI spec for all of the API services in your environment. For more options to create ApiDocs, see the Create ApiDocs guide.

  1. Describe the app services that you created in the previous tutorial. Check the annotations of the services. For more information about the annotations or to update them, see the Create ApiDocs guide.

      kubectl describe svc -n tracks tracks-rest-api | grep "Annotations" -A4
  
      kubectl describe svc -n users users-rest-api | grep "Annotations" -A4
  
      kubectl describe svc -n pets pets-rest-api | grep "Annotations" -A4
  
      kubectl describe svc -n store store-rest-api | grep "Annotations" -A4

    Example output:

      annotations:
   gloo.solo.io/scrape-openapi-pull-attempts: "60"
   gloo.solo.io/scrape-openapi-retry-delay: 1s
   gloo.solo.io/scrape-openapi-source: /swagger.json
   gloo.solo.io/scrape-openapi-use-backoff: "false"

  2. List the ApiDocs in each app’s namespace.

      kubectl get apidocs -A

  3. Describe one of the ApiDocs, and verify that the ApiDoc has the OpenAPI spec for the service. For more information, see the Verify ApiDocs guide.

      kubectl describe apidocs -n tracks

    Example output:

      ...
Spec:
  Openapi:
    Inline String:  {"components":{"schemas":{"Author":{"properties":{"id":{"type":"string"},"name":{"type":"string"},"photo":{"type":"string"}},"type":"object"},"Module":{"properties":{"authorId":{"type":"string"},"content":{"type":"string"}

Create API products

API products are what your users find and use in your developer portal. The API products might represent an entire product with many APIs, such as a pet store, or a large feature within the product that you want to treat separately, such as a checkout cart. Each API product might represent a particular version of your API.

API products target the route that the backing app is available on. This way, you have greater flexibility in how you structure your API products. To bundle your APIs into an API product, you use a Gloo RouteTable custom resource.

For more information and advanced use cases such as versioning, see the Create API products guide.

  1. Create a route table to represent an API Product for the tracks app.

      kubectl apply -f - << EOF
apiVersion: networking.gloo.solo.io/v2
kind: RouteTable
metadata:
  name: tracks-rt
  namespace: gloo-mesh-gateways
  labels:
     portal: dev-portal
     api: tracks
spec:
  hosts:
  - api.example.com
  virtualGateways:
  - name: istio-ingressgateway
    namespace: gloo-mesh-gateways
  http:
  - name: tracks-api
    labels:
      usagePlans: dev-portal
    matchers:
    - uri:
        prefix: /
    forwardTo:
      pathRewrite: /
      destinations:
      - ref:
          name: tracks-rest-api
          namespace: tracks
        port:
          number: 5000
  portalMetadata:
    apiProductId: "tracks"
    apiProductDisplayName: "Catstronauts Course Tracks"
    apiVersion: "v1"
    title: "Catstronauts REST API"
    description: "REST API for Catstronauts to retrieve data for tracks, authors and modules."
    termsOfService: "You must authenticate to use this API! And other Terms of Service."
    contact: "support@example.com"
    license: "License info, such as MIT"
    lifecycle: "Supported"
    customMetadata:
      compatibility: "None"
EOF

  2. Create another route table to represent a single Petstore API product that routes to the backing pets, users, and store API microservices.

      kubectl apply -f - << EOF
apiVersion: networking.gloo.solo.io/v2
kind: RouteTable
metadata:
  name: petstore-rt
  namespace: gloo-mesh-gateways
  labels:
     portal: dev-portal
     api: petstore
spec:
  hosts:
  - api.example.com
  virtualGateways:
  - name: istio-ingressgateway
    namespace: gloo-mesh-gateways
  http:
  - name: pets-api
    labels:
      usagePlans: dev-portal
    matchers:
    - uri:
        prefix: /pet
    forwardTo:
      destinations:
      - ref:
          name: pets-rest-api
          namespace: pets
        port:
          number: 5000
  - name: users-api
    labels:
      usagePlans: dev-portal
    matchers:
    - uri:
        prefix: /user
    forwardTo:
      destinations:
      - ref:
          name: users-rest-api
          namespace: users
        port:
          number: 5000
  - name: store-api
    labels:
      usagePlans: dev-portal       
    matchers:
    - uri:
        prefix: /store
    forwardTo:
      destinations:
      - ref:
          name: store-rest-api
          namespace: store
        port:
          number: 5000
  portalMetadata:
    apiProductId: "petstore"
    apiProductDisplayName: "Pet Store"
    apiVersion: "v1"
    title: "Pet Store REST API"
    description: "Totally awesome API for all things pets!"
    termsOfService: "You must authenticate to use this API! And other Terms of Service."
    contact: "support@example.com"
    license: "License info, such as MIT"
    lifecycle: "Supported"
    customMetadata:
      compatibility: "None"
EOF

  3. Create a virtual gateway that listens for traffic on the api.example.com host domain that your API products are available on.

      kubectl apply -f - << EOF
apiVersion: networking.gloo.solo.io/v2
kind: VirtualGateway
metadata:
  name: istio-ingressgateway
  namespace: gloo-mesh-gateways
spec:
  listeners:
    - port:
        number: 80
      http: {}
      allowedRouteTables:
        - host: api.example.com
  workloads:
  - selector:
      labels:
        istio: ingressgateway
      cluster: $CLUSTER_NAME
EOF

  4. Optional: Verify your API product routing setup.

Next steps

Next, create the backend and frontend for your developer portal.