If you provide an API to your developer community, you might be familiar with OpenAPI (but don’t worry if you aren’t – I’ll explain everything). Perhaps you’re already using it to define all the endpoints and methods available, to generate documentation, or to support client apps like Postman.
What if you could also use your OpenAPI definition to improve your API security by ensuring that all requests to your API match the patterns supported by your server? What if that also meant reducing load on your servers?
Request validation is an important part of any web application or service. It ensures that your server is receiving data in the format that it requires. This helps mitigate potential bugs (like unexpected errors and slow or invalid responses), and security vulnerabilities that might be exposed when the consumers of your API send wrong or malicious request data.
There is nothing wrong with processes failing, and of course any good web application will include error handling. However, at scale, there are mounting costs both for the client, in terms of increased request latency, and for the server – in terms of resources. The deeper a request goes into a system before it fails, the more complex the error handling needs to be; the more expensive handling that transaction is; the longer it takes for the client to get a response, and the higher the chance of a malicious client discovering something interesting about the system architecture. The costs – and the risks – increase with depth.
That’s why it’s a good idea to fail fast and shallow, by performing validation as early as possible in the request lifecycle. With Fastly’s Compute@Edge, you can do this before a request reaches your origin!
If the words “API specification” seem intimidating, think of flat-pack furniture, or, better yet, LEGO sets for grown-ups. These come with instructions for assembly, as well as for individual parts – a bit like a blueprint. A good blueprint will allow you to build something that looks and works exactly like it’s meant to.
The principle behind the OpenAPI Specification (OAS – the industry’s most popular API specification format) is similar. It’s supposed to act as a blueprint for describing RESTful APIs.
To adopt OAS, you create a document that defines your API in OpenAPI’s standard format. Such documents are both machine and human-readable, which enables anyone to discover and understand the capabilities of a service without access to source code, additional documentation, or inspection of network traffic.
If you’re lucky, you might already have OpenAPI definitions for your APIs. If not, don’t panic! There are tools that can help you generate these documents from other API definition formats, source code, and even network traces.
Compute@Edge, Fastly’s serverless compute platform, allows you to build high scale, globally distributed applications – without having to manage the underlying infrastructure.
In a few short minutes, you’ll have a working Compute@Edge service, configured to perform basic validation of API requests against an OpenAPI definition. On every invocation, this service will ensure that:
- All required request parameters in the URI, query string, and headers of an incoming request are included and non-blank.
- Any applicable request payload adheres to the OpenAPI request model of a corresponding API operation.
Let’s do this!
If you’ve never experimented with Compute@Edge, start by getting set up.
fastly compute init \
The project you just created comes pre-configured with an example origin (httpbin.org) and an OpenAPI definition, so if you don’t have your own OpenAPI document handy, you can skip this step. Otherwise, now is a good time to:
src/definition.jsonwith your API definition.
Important! API definitions must be:
Replace references to
fastly.toml, with your API origin – and make any other configuration changes, as necessary.
fastly compute serve to run the Compute@Edge service on your local machine. Check the console to see both stdio and log output from your application.
Next, open up a new terminal instance and try sending valid and invalid requests to the local server:
# Valid request: returns the response from the origin
curl -L -X \
POST 'http://127.0.0.1:7676/anything' \
-H 'Custom-Header: Hello!'
# Invalid request: returns a synthetic response (400 Bad Request)
curl -L -X \
You can also run
fastly compute publish and follow the steps in the wizard to publish your Compute@Edge service online.