Introduction to API Studio

Updated 1 week ago by Rahul Lahiri

Let us go over the main elements of the API Studio user interface before jumping into a hands-on tour of the product.

API Studio capabilities

  1. API Editor: The API Editor allows you to create/edit API requests to send to the service you are developing, send them to the service running in either an IDE or in the cloud, view the responses, and identify changes by comparing the responses to saved versions. In addition, it allows you to create/edit mocks for egress requests (if necessary), configure where to send both ingress and egress requests, review the results, and save the traces.
  2. API Catalog: The API catalog aggregates all data that is available in API Studio. This includes collections created by all users across the organization, test suites created using Mesh Dynamics, as well as all API data captured from CI tests (only available if you have the Mesh Dynamics agents deployed in your CI). The API catalog is a valuable starting point for finding API requests to use during debugging and testing.
  3. Test Runner: From the test runner, you can initiate a service test for your API, or a full end-to-end regression test of your application. Service tests could run from the developer's laptop or from the CI pipeline. This is useful for organizations that are moving towards independent service deployments in their CI/CD process. For end-to-end tests, all the services and databases must be live in the test cluster
  4. Test Results: Review the results from the service tests and regression tests, diagnose problems, file bugs, and take other actions based on the test results.
  5. Feedback: Submit suggestions or bug reports for API Studio to the Mesh Dynamics team.
  6. Help: Link to online help docs for API Studio.
  7. User: Account actions.
  8. Logout

API Editor overview

  1. Trace: Trace of the request execution for the API request. It shows a summary of the request sent to the service, as well as all the egress requests from the service to other services.
  2. Ingress request: The API request sent to the service.
  3. Egress requests: Requests sent to other services during the API execution.
  4. Request details: Details for the selected request. The selected request can be either the ingress request or one of the egress requests. You can see full details of the request including the API path, headers, query parameters, and body.
  5. Request status: The HTTP status returned from the request execution.
  6. Response details: The response for the selected request.
  7. Egress request routing configuration: The egress request routing configuration determines where to forward each egress request coming to the API Studio from the IDE. The requests can be forwarded to a live service (for example in a dev cluster) or to Mesh Dynamics mock services. Multiple configurations can be created to easily switch between different configurations.
  8. Environment for service being tested: This configuration parameter defines sets of environment variables that are used by the API Studio. The most common use is to define where API Studio sends the ingress request. The request could be sent to a localhost address when the service is running locally, or to a cloud location.
  9. Run: Initiates the request to the location specified in the request URL and the environment setup.
  10. Save: Saves a trace to a collection.
  11. Duplicate trace: Duplicate the current trace in a new tab.
  12. Import: Import cURL requests as API Studio requests.

API Catalog overview

  1. Source type: There are 3 types of sources for the API catalog -- test files, captured API traces, and collections created by users.
  2. Source file: The specific file or collection depending on the source type.
  3. FIlters: The service and API filters can be applied to narrow down the requests that are shown in the Requests table below.
  4. Services: Filter for requests captured from different services.
  5. API: Filter for APIs from the selected service.
  6. Requests table: All requests available in the selected file or collection filtered by the filter criteria applied.
  7. Pins: The pins are used for selecting any two requests in the catalog to compare. Pinned requests can be from across dates, collections, etc. Only two requests can be pinned for comparision at a time.
  8. Compare pinned requests: Use this to identify what has changed in an API behavior, or to check if two APIs are providing largely overlapping functionality.

We will cover the Test Runner and Test Results sections separately when we go deeper into the service and regression testing capabilities.

Next steps

Now let's install API Studio on your laptop.


How did we do?