We’re always talking about the [API design-first workflow](TODO three step article), where backend teams design the API (with Studio another editor), then share the mocks with the client application developers to get feedback early on (to make sure they’re building something that’s actually useful before they invest a bunch of time writing code.) There’s a lot of ways to run a mock server, but we’re launching a new option: hosted mocking!
Stoplight is pretty proud of our open-source HTTP mock server Prism. We released Prism v3 last year as a TypeScript rewrite, supporting OpenAPI v2 and v3 (with one more description format to be announced soon!)
As much as we love this tool, getting it up and running could be tough for some.
API client developers wanting to run a mock server would need to download Studio Desktop to use the built in Mock Server, or install Prism as a node module or docker container to use the Prism command-line interface. This is fine for some developers, especially those who already work with node modules or docker a lot, but it’s all more things to learn for people who want to just want to talk to a mock server.
To help out here some teams might have deployed Prism to a VPS, some Platform-as-a-Service (PaaS) like Heroku, or [run Prism as a serverless function](TODO serverless). Stoplight’s whole thing is building tooling so that API designers and developers don’t have to roll their own DocOps / DesignOps, so whilst you’re welcome to keep doing this, we wanted to make things even easier for you.
How do you make things better? Get it in the cloud! We’ve added Prism to our Platform, and we call it [Hosted Mocking](TODO docs?). It’s available in Studio Desktop, Studio Web, and anywhere else the Request Maker shows up, including API reference Documentation under the “Try it Now” tab, embedded HTTP calls in Markdown documentation, and our API knowledge base Explorer.
When you hit [Publish in Studio](TODO URL) (or via the CLI), Stoplight analyzes all of the [relevant files](TODO Project config), reads Markdown documents it’s told to read, and more importantly for mocking it looks at all your API description documents: OpenAPI and JSON Schema. Until now these file scans were just for update the published documentation, but this same process is now used to update hosted mocks.
Hosted then offers you an alternative Server URL, so if your OpenAPI document had:
servers: - name: Production url: https://example.com/api paths: /hello: get: # ...
You could swap out that server URL for your Hosted Mocking URL:
TODO Workspaces? https://example-org.stoplight.io/repo/1234/hello
The actual contents of the responses depends on the examples in the API Description, and if the request prefers static or dynamic mode,
Read more about all that in the docs TODO
Studio, Docs and Explorer all have a HTTP Client we call request maker, and hosted mocking is built right into that. You don’t need to turn anything on its just there now.
!(TODO Screeny options)
If - like me in the past - you have duct-taped a plethora of random tooling together in order to get shared mock services running, you can go ahead and delete all that. Pay off your tech debt with a swift
rm -rf, switch to Hosted Mock, and let us handle this for you so you can focus on your actual job. It’s literally our job. 🙌