Serving static content and files with wiretap

When building a user interface to an API, it may mean that in order to effectively test the API, you need to serve some static content or files along with the API.

Why do I need this?

If the user interface is a web application, and the web application and the API are served from the same host, then in order to effectively use wiretap, the application would need to be served by wiretap as well.

Can I use a different host?

You can, but then you run into the problem of CORS (Cross Origin Resource Sharing).

Why can’t wiretap deal with CORS?

It can, and it does! response headers are automatically added to all responses served by wiretap to allow CORS.

The reason this feature exists however is to avoid the need to re-wire applications to use a different host/port for APIs.

Serve static content

Use the -t or --static flag, you can specify a directory to serve static content from.

Use the configuration file

When using a configuration file, the staticDir property operates the same as the -t property.

Catch-all paths

The application might need multiple catch-all paths that serves the same index.html file.

using the staticPaths property as part of a configuration file, multiple path globs can be specified to act as a ‘catch all’ to ensure all matching traffic is redirected to the index.html file, but keeping the original route in-tact, so the SPA can load content effectively.

For example:

staticPaths:
  - /en-US/app/*
  - /some-other-app-path/*/something/*

This will ensure all traffic to /en-US/app/* and /some-other-app-path/*/something/* will be redirected to the index.html

Configuring the index

If the application uses something other than index.html, it can be changed using the -i or --static-index flags, or can be configured using the staticIndex configuration property.