Skip to content

Latest commit

 

History

History
14 lines (10 loc) · 2.17 KB

design-mock-servers.md

File metadata and controls

14 lines (10 loc) · 2.17 KB

Design Mock Servers

Mocking an API during the design process provides a robust way to make an API as real as possible for all stakeholders involved without having to actually write any code, providing static or dynamic representations of each API as it is being designed by technical and business stakeholders.

Elements

These are the elements of mock servers for use as design aids.

  • Names -
  • Collections - A machine-readable artifact that acts as a container for storing and organizing multiple API requests, providing an executable, self-documented reference for a complete API, a subset of an API, as well as workflows containing multiple requests from across many different APIs in a specific order, with a precise business function.
  • Environments - Machine-readable environments for APIs allow for abstracting away common elements of an API environment from the definition of each API, allowing different environments to be paired with OpenAPI and collections for each API at design, development, and build time.
  • Public - Designating a workspace, APIs, collections, environments, and monitors having a public visibility that makes them discoverable via the public API network and search engines, increasing the audience for an API by making it available publicly, while still limiting who can actually edit artifacts and change configuration, limiting engagement with public consumers to watches, forks, and commenting on APIs and collections.
  • Keys - API keys provide the simplest form of access to an API, allowing consumers to sign up for an account, define what their application is, and then receive a key they can include in headers or other parameters to identify themselves, ensuring that API producers are fully aware of everyone who has access to an API, and all consumers have a way to clearly identify themselves and receive personalized usage data for each key.
  • Usage - Once an API is implemented into production code, a developer decides whether to deepen adoption of your API. They might increase traffic or accommodate other user scenarios. This is when developers take a hard look at latency, responsiveness, flexibility, and scalability.