Analyzing web application APIs using Edge DevTools

Much of the code we write these days depends on the web. After all, why develop a new protocol when you can add a custom payload to HTTP? There’s no need to create a new layer in the networking stack when there’s already one that’s extensible, flexible, and secure. Instead we can take advantage of the GET and POST functions in HTTP and work with RESTful APIs.

Yes, that’s oversimplifying, but in practice very few occasions demand something completely new. HTTP is a simplification, yes, but it’s also an obfuscation. If everything we use is HTTP under the hood, how do we build testing and development tools that can work with those APIs?

Although the Open API Initiative and other approaches go a long way to codifying how we describe and implement HTTP-based APIs, we’re usually left cobbling together a mix of different tools to build and test our API calls. Postman is probably the most popular and most familiar tool out there, but it’s separate from both our development environments and our browsers, making it hard to be sure that we’re designing and testing HTTP calls in the context of our applications.

The Chromium evolution of Edge’s developer tools

Microsoft’s switch to Chromium in the new Edge browser has given it the opportunity to extend its built-in developer tools, building on its own history of developer tools in both Trident and EdgeHTML and the work being done in the Chromium open source project. Each release of the stable and developer versions of the browser adds new tools, in the release F12 console and behind its experimental flags.

The experimental developer tooling is well worth an exploration, as it contains many useful tools that haven’t quite got the production-level polish but can still help you solve significant issues in your code. To turn them on, launch the DevTools pane with F12, then in the top right of the tools pane or window (I prefer the option of a pop-out window rather than a pane, as I can drag the window to a separate monitor) click the Settings icon. In the Settings screen choose Experiments and then select the new features you want to use.

The latest stable release, Edge 85, contains several new tools in its experiments, including a much-needed CSS Grid debugger. However, the most interesting new feature allows you to both edit and replay network events in the new Network Console.

Using the Network Console with REST APIs

At first sight it’s a way to record and analyze HTTP requests, capture recent activity, and drill down into server responses beyond the normal HTTP response codes. If you’re working with REST APIs and using a browser for debugging, you know that there’s a lot more to an API than a 200 OK message, especially if you’re working through a REST proxy or an API broker. Knowing that the HTTP server that’s acting as a façade to your API is working isn’t the same as knowing that the API is returning the values you expect.

The real advantage of the Edge DevTools Network Console is the ability to use it as a quick way to try out HTTP APIs without writing any code. You’ve probably used tools such as Postman for this, but they’re outside the browser and best suited for developing and testing APIs from scratch. The Network Console works similarly, giving you a scratch pad to quickly try out API URLs.

Building and testing HTTP queries

To test an API, open a blank Network Console from F12, and then click Create a Request to open the HTTP query builder. You can pick from the common HTTP query directives, including the common POST and GET queries used in RESTful APIs. Start by using common API explorers such as Microsoft’s Graph Explorer or the Swagger Pet Store to check that you’re constructing requests correctly and that you understand how to use authentication tokens to work with restricted APIs.

Once you’ve made a query, the tool displays the status response, how long the query took, and the size of the response. You can download the response JSON to test parsers or preview it in the console. The built-in JSON preview parses the response and shows key/value pairs, as well as the response body, any headers, and cookies.

At heart it’s a very simple tool, but often that’s all you need. At this point in its evolution it’s probably best to treat the Edge DevTools Network Console as a quick, ad hoc testing tool. The ability to replay recorded network activity is helpful in conjunction with server-side performance testing tools. You can send identical traffic to a server, allowing you to repeat problematic interactions automatically.

The ability to edit calls in the console is useful, as you can capture API calls from inside page content and then use them as the basis of tests, tweaking the content as needed. Security engineers will find this approach convenient; they can identify possible attacks on a site or service and then experiment with malformed payloads to explore failure modes.

What’s needed for the future

For a tool like this to be an alternative to Postman, it does need more features, such as the ability to import Open API definitions. Swagger-format JSON is a standard way of exchanging API information from open services, like the Microsoft Graph. If you could import these definitions into the Network Console to pick and choose the APIs to test (alongside the Open API self-documentation features) developers could use their browser to explore available APIs, and try them out before importing the definitions into their development environments. As it stands there’s some form of import function, but it’s unclear what’s meant by collection or environment, though neither works with Open API JSON files.

Microsoft is handling the switch to the new Edge well, with a run of quality stable releases. It’s good to see the DevTools team using this to innovate and provide developers with a set of quick, easy in-browser tools that give you insights into how your code is working. The new Network Console takes that further, and into working with your APIs.

Sadly the tool doesn’t yet work with the Edge Network plug-in for Visual Studio Code, but it’s easy to see how a future update could work with your local API development, helping you build and test REST APIs on a local machine without leaving your editor. Code’s Electron foundations make it relatively easy for Microsoft to add browser tools like this, breaking the walls down between editor and runtime in a much-needed, developer-friendly way.