We check out Everest, an open source API testing project. 

Testing is a fundamental part of the API development cycle. Accordingly, the tools used for testing are just as essential as the test itself. In the average development cycle, thousands, perhaps tens of thousands, of API queries will be passed through and tested to ensure data integrity, response clarity, and user experience.

Everest is a tool that promises to provide an excellent environment for testing in a lightweight distribution. Does it live up to its promise?

What is Everest?

Built by Rohit Awate, Everest is an open source API testing client that is designed to be lightweight, portable, and customizable. Originally called RESTaurant, the client is built in JavaFX, and includes a custom synchronization server called Summit. Together, the application offers a great way to test APIs without the significant overhead of large clients with complex call functions.

Both Everest and Summit are still very early in development, so much of the promise of this solution exists in wishlist form – in other words, Everest and Summit still have quite a ways to go. Everest is planning on full support for both OAuth standards, first focusing on OAuth 2.0, and then OAuth 1.0, but as of today, it does not support either. The long-term goals of Everest per their documentation are to be the “equivalent of Postman’s Collection or Insomnia’s Workspace,” supporting a wide variety of functions required for complex API testing processes.

Everest Feature Set

As of today, Everest has a core set of functional systems for effective API testing. First and foremost, Everest supports the most common API verbiage – GET, POST, PUT, DELETE, and PATCH – enough coverage for most APIs that may come through the system.

As an API testing solution, the method of querying is the most important element of the greater system. Everest focuses heavily on request building, with support for request headers, query parameters, syntax highlighting, and key-value pair management. Additionally, it supports a wide variety of HTTP status codes, complex content types, time and size valuation, and a JSON visualizer.

One of the main focuses of Everest is the improvement of quality of life in the API testing environment. A big part of this is the fact that Everest has a history collection feature, allowing previous queries to be recorded over time, and allowing searches to be run on these requests, locating data in the target, headers, method, body, and files added to the request. Everest has what it calls an “intelligent ranking” system to mark the relevance of these search results, further improving that process.

Everest also supports multi-tabbing in the application, utilizing pseudo-tab-switching to allow for a great many API tests to be occurring. It can store data concurrently while maintaining a low memory footprint. This means that many complex requests can be handled in the same view without massive memory requests, which is traditionally a problem for API testing solutions, which often focus on a single command or request at a time.

Summit

One of the things that makes Everest unique is its synchronization server called Summit. In essence, Summit is simply a synchronization system that allows for cloud storage – but in practice, it does more. Summit provides an Extension API that allows for greater leverage and functionality, producing unique value in the Everest system. For example, Everest cites examples such as synchronizing data to Google Drive, or visualizing response data in a structured way – this Extension API allows for a broader range of transformations and interactions than would otherwise be possible.

Additionally, Summit provides a local mock server solution that allows for the creation and testing of RESTful services using custom endpoints. This, in tandem with the Extension API, allows Everest to test in real time, iterating upon developed endpoints at each step of development. Together, Everest and Summit elevate each other to loftier heights than they achieve on their own – for that reason, they should be considered as a singular unit.

Pros

Everest, and therefore Summit, have some pretty strong arguments in its favor. First and foremost, because Everest is written in Java, it’s lightweight, even compared to similar solutions in other languages. It’s resource light due to this fact, making it great for low power or mobile testing.

More to the point, because Everest is based on Java, this means that it’s highly usable on a wide variety of systems – billions of devices around the world run some version of Java, meaning that there’s a very good chance any device faced with Everest would be able to run it.

While less important than technical details, the ability to customize Everest is pretty awesome. A lot of tools are hard to use simply because of their UI and design choices. Being able to change those choices on a user-level basis generally leads to better user experience.

Speaking of user experience, the presence of Summit is a big benefit to using Everest versus other solutions. Being able to sync content to cloud providers is excellent, and to that end, Summit looks like a great solution. The bigger story here, however, is the presence of a mock server solution, which can make testing faster out of the box.

Cons

That’s not to say, of course, that Everest is perfect. Generally speaking, while the appearance of the applet is customizable, the UI, in general, has some design issues. This may have been isolated to the testing environment used, but the UI can seem a little rough.

Smaller UX issues should be noted as well, such as with how history is handled. History can be helpful, and being able to search history is great, but every single query is logged, resulting in an overly verbose area. Clearing this area out is not a function that is made abundantly clear, and in fact, doing so requires deleting specific files in the folder generated when first running the applet. Small user experience issues like this are rife throughout the whole experience.

That being said, these cons are significantly less impactful than the aforementioned pros. Keeping your expectations at an appropriate level can help as well – this is essentially a solution in development, and because it’s still relatively early in that development, its offerings have yet to mature.

A Basic Workflow

In this example, we’re going to use Everest to call a weather API. First, we need to download and run Everest itself. Everest requires the Java Runtime Environment (JVM) to work, so if the client in question does not have this, this is a prerequisite installation. Once Everest is downloaded, launching the .jar file will bring up this interface:

This is the base interface within Everest. To the left of the screen, you can see the history pane, which tracks all of your queries over time, and allows for these queries to be searched. In the top pane, we can see the query builder and the various sub-areas within the query engine where we can state parameters, pass through authorization tokens, and define both the header and body content.

If you click on “GET” in the query builder, the following menu pops down:

This menu contains all of the currently supported verbiage and is the main area in which queries are built. For our purposes, we’re merely going to make a GET request to the base endpoint to test that it is, in fact, up and running. We can do this by entering the API endpoint into the GET request builder. The output, formatted as JSON, looks like this:

Here, we can see a simple output to our basic query. A 200 code allows us to confirm that the API is alive and replying to traffic. In this basic response, we can see a few of the key elements for testing purposes. While this has been put into a JSON format, the drop down for formatting allows for a few interesting options, including Plain Text, JSON, XML, and HTML. We can also see the size of the output – in this case, 22 Bytes – as well as the response time – 1,701 milliseconds in this case.

Now let’s make a more complex request:

Here, we’ve made a request (at the recommendation of the API documentation) to poll the API for the weather at a given GPS coordinate – this request roughly translates to Linn, Kansas, USA. Here we can see the bottom part of the API response – we have a statement of the location, the weather value, the properties of the area in question, the properties and geometry of the reference data, and more.

This is where we can start to see more significant data on testing individual responses – we can see whether the API responded too verbosely, or whether the size is too large. We can test for security lapses by finding out the sum-total of data output, or even see whether we can do mass id polling – which may, in some cases, be something rate limited rather than something publicly accessible outside of specific queries.

Let’s Ask The Creator

We reached out to Rohit Awate to better understand his motivations behind developing Everest and Summit. It seems a big motivation was to create a more lean testing environment.

“The primary motivation behind Everest were the memory usage figures of Postman. They were consistently in the 700-800MB range. I’m not a particularly big fan of Electron and the heft that comes with it. I thought I could do better and that’s why I started building Everest.”

When it comes to community awareness, Rohit acknowledges that JavaFX may have been a controversial language choice, but he believes it is worth the time investment to learn as it is super lightweight.

“From the discussions I’ve had online, people find JavaFX to be a controversial choice thanks to Java’s notoriety for being heavy, but I had used it for a couple of projects before and it was lighter than Electron.”

Final Thoughts

Everest and Summit have quite a lot going for it as a solution pair – the lightweight application uses ubiquitous software libraries to do what it does, and it does it quite well.

While smaller UX issues persist, the fact that this is still relatively early in its development should be used as context for such shortcomings. Rohit reminds us that Everest is “still a work in progress,” but he aims to “release a stable version along with Summit by the end of this year.” Speaking of Summit, Rohit also updated us with future plans to scrap Node/Express code in favor of Golang.

Ultimately, Everest is a quite useful, powerful solution on its own – the addition of Summit adds the promise of greater cloud functionality and a testing regimen that is quite useful for any RESTful API tester.

What do you think about Everest? Are there any other API testing tools you prefer over Everest and Summit? Let us know in the comments below!