Advanced REST client application

Advanced REST Client version 17 release

2022-02-01T06:55:00.002+00:00

Version 17 of Advanced REST Client has been released. You can install it from ARC's releases page.

This release was focused on consolidating so far distributed code-base. We have merged most of the existing libraries into 4 main repositories. This allows us to focus on building new features instead of compatibility between the libraries.

Besides the great consolidation, this version comes with several new features, bug fixes, and general improvements.

New features

Added proxy settings in the application configuration
Added an option to read the OS' hosts file and combine the content with the app defined hosts
Added the ability to export the saved requests as a HAR file
Added a context menu entry for input fields to insert a variable
Added variables support in the authorization editor
Updated the UI to change the redirect URI for a single HTTP request
Added support for OICD (OpenID Connect) authorization

Improvements

Removed support for CodeMirror. ARC uses Monaco editor only.
New API Console - the next (not yet published) version of MuleSoft's API Console - the API documentation tool
Removed update channels (alpha, beta, latest) from the application updater

Added the app updater option to install a pre-release version
Dropping support for the "alpha" release

Added notifications when processing API project (with the spec)

Deprecation

Removed querying to the application backend for new messages
Removed custom Analytics service (Google Analytics is still there)

Fixes

Fixed setting the port information in the Python code snippets
Fixed setting code snippets after changing authorization settings
Fixed #437 - changed the definition of binary data in the response view

We hope you will love this version. Please, give us your feedback on the project's GitHub page.

The future of ARC projects

2021-12-10T18:26:00.006+00:00

In the discussion “Redesign data storage - removal of Saved requests”, I proposed ending of “saved” requests in the Advanced REST Client, moving all existing “saved” requests to a “default” project, and redesigning what a project is. I was unclear how to evolve this functionality back then, but today the path is clear. This post explains the way forward for ARC projects and the invitation for open discussion before finalizing the spec and turning it into a code.

History of projects

Advanced REST Client (ARC) projects are simple “Saved” requests lists. Saved means they are stored the same way as the “history”, but the application allows defining additional metadata like name or description. A project conceptually is an object with a name and description with zero or more saved requests. The purpose of having a project is to group “saved” requests and organize them in the application. Otherwise, it serves no purpose.

Projects as functional lists

After reading comments in the post referenced at the top of this post and after having hours discussing what an API project means, I decided to change ARC’s projects. I’ll explain where I plan to go with ARC projects in the next paragraph. Note that this is an intermediate step to add support for API design in ARC. To ensure backward compatibility, I plan to implement changes to the ARC project that is the groundwork for future development of the application targeting API design.

We base the new concept of a Project in ARC on correlating HTTP requests for the same API into a single structure. You will be able to make “folders”, which are a way to group HTTP request into even more defined lists. Each folder and the project can have a list of environments defined on each level. A folder inherits environments from a parent. However, a folder may set a flag to limit this inheritance. An environment is a definition of a server, variables, and authentication. This way, you can switch environments (variables and server definition) to make HTTP requests to different physical environments without changing any of the HTTP requests definitions.

A “Project Runner” will allow you to run requests defined in a project or a folder one-by-one and render the execution log in the UI (CLI, the application).

Finally, a project is a formal definition used in ARC. It is a well-defined standard and encapsulated, meaning all information is included in the project. The base format for a project is JSON. However, through the AMF parser, we plan to add support for the YAML format.

Design principles

We design projects to be accessible, standard, and usable.

Accessible as we build the libraries used in ARC as NodeJS libraries. You can use these libraries to make your integrations on top of them. From these libraries, you can manipulate the project and execute HTTP requests. On top of the libraries, we plan to build a CLI that performs a set of designed operations to manage and execute a project. Finally, we will use the same libraries in ARC as a functional layer under the UI.

Standard as we define data using industry standards (formats) or provide interfaces to exchange ARC formats to other standards. This way, you can switch from ARC to other tools and back.

Usable, we define it as a connected experience. Operations in the UI can also be done in the CLI and with the libraries.

Use cases for ARC projects

API development

During the API implementation, a developer creates a project for the API. The developer creates a folder with HTTP requests that perform authentication and set variables with the access token. They configure a server with the base URI and use reserved variables in the HTTP request definition to access the value. Next, the developer creates a folder with a list of requests related to manipulating a resource in the API. They define a set of CRUD operations.

During the development, they execute the requests in a folder to ensure the changes they make in the code do not influence the built application’s functional layer.

Naive testing

The developer executes the request in a folder in the CI/CD pipeline as unit tests. They use NodeJS libraries or a CLI to integrate the testing with their custom pipeline. We call it naive testing as even though these tests can function as a test layer for an API, they cannot replace structured testing of an API in the long run.

Current projects and “saved” requests

Given the discussion we had in the referenced issue report, we plan to end-of-life of the current projects and “saved” requests. All currently “saved” requests that do not belong to a project we will move to a “default” (or similar) project.

Beyond the current scope of changes

After introducing the new projects in ARC (we target v18, H1 2022), we plan to work on structural API testing. We are missing details, but we plan to design a testing language for APIs, which the libraries translate to the code at runtime. This way, we design tests like we design APIs and the runtime libraries take care of the execution of the test. We believe it is a highly scalable way of testing APIs as this allows us to design once and run in different environments.

Please, let us know what you think. We are happy to hear your perspective on this. Before implementing the new projects, we can still shape the whole concept together. You can join the discussion in this GitHub post: https://github.com/advanced-rest-client/arc-electron/discussions/434

Regards

Pawel Uchida-Psztyc

Version 17 - beta release

2021-11-17T21:23:00.006+00:00

Dear ARC users,

Recently we released version 17 (beta) of the Advanced REST Client. In it few changes were requested for a very long time, so we are delighted that they will soon be available in the stable channel.

See the list of changes below.

Added support for HTTP proxy

We are introducing new settings in the application configuration to enable HTTP proxy. You can now allow proxy for HTTP requests. These settings work for both HTTP (classic proxy) and SSL (tunneling).

More privacy

We removed the in-app messages and the application's custom analytic service. From version 17, we won't be sending any data to the application backend. We are keeping Google Analytics to analyze how the application is used (so we can make product decisions). Still, it is up to you to agree to enable Google Analytics (it's disabled by default).

Next version of API Console

Are you using ARC to render documentation for your APIs designed in RAML or OAS? In version 17, we are introducing the next version of API Console - the API documentation tool. This version is not yet published by MuleSoft. It's a complete redesign of the UI and the application architecture. We hope to hear feedback from you about the new experience!

Support for HAR

HAR (HTTP Archive format) is commonly used to store HTTP data. Version 17 allows you to export an HTTP request in the request editor as HAR data.

New features in the authorization

Now you can perform OIDC (OpenID Connect) authorization from the request editor. It is a protocol designed on top of the OAuth2 protocol. We also changed the application to allow you to change the redirect URI in the request editor. Finally, now you can insert a variable into any authorization field, and they will be processed when preparing the request for the transport.

HTTP body editors

We removed support for CodeMirror, and now we only support Monaco (by Microsoft). This was we can focus on other aspects of the application development instead of the libraries we use.

OS' hosts file

We added an option to read the OS' hosts file and combine the content with the app-defined hosts. This way, you can test your virtual-hosts configuration of an HTTP server while keeping the configuration in the hosts file only.

User input

We added a context menu entry for input fields to insert a variable. Right-click on an input field and select "Insert variable." This brings a dialog that allows you to choose a variable to insert from the current environment.

Application auto-update

We removed update channels (alpha, beta, latest) from the application About screen. Now you can select an option to install a pre-release version of the application. This version is a release candidate. Therefore we dropped support for the "alpha" channel.

We are excited to hear your feedback. Please, install the pre-release version of the application, see what's coming and let us know your thoughts. If you would like the application to be developed in a specific direction or need a new feature, create an issue report or start a discussion on our GitHub page.

Version 16 Released as Alpha Release

2021-01-31T00:40:00.002+00:00

Fixes #304

This fixes #304 which is a long running effort to upgrade application logic and UI.

You can try the new application by cloning this repository and checking out the `redesing2020` branch. Then installed dependencies (`npm i`) and start the application (`npm start`).

After over a year of redesigning the application and upgrading its code base I am proud to announce that the application with version 16.0.0-alpha.6 has been released today. This is a significant milestone for the application from the development perspective because the entire code base has been redesigned and upgraded to use Type Script to ensure stability of the code base and a new centralized DOM Events module that manages internal communication. Because of that we will be able to accelerate the development of the application, reduce number of issues, and simplify the development workflows. Also the number of components used by the application has been significantly reduced to help with the developer work flow.

From the user perspective this release comes with complete redesign of the UI: new navigation and workspace that support different types of editors (not only HTTP editor). In the future this redesign will allow us to introduce new functionality to the application, like support for Protocol Buffers, GraphQL queries, or structural API testing capabilities. This wasn't possible with the previous application and information architecture.

We are also working on a new documentation for the application that includes video tutorials, and

Below is the complete change log for the v16 release for the end-user.

Now the navigation has a navigation rail to move between different sections of the navigation. This makes space for other planned types of navigation
ARC now uses Monaco editor to edit the request body. This can be changes back to CodeMirror in application settings.
Redesigned the response view. Now the response view has panels that can be opened on demand. The old response view was split into several panels.
The request panel now allows to import cURL command
Application navigation now can be resized. It can be also hidden by clicking on the currently selected menu icon.
Response view can be now resized as the panels are being created as stacked on top of each other.
Redesigned settings panel. Added new UI and tons of new options controlling application behavior.
Redesigned request workspace for the load time.
The authorization settings now can be configured but not enabled. Also, the application allows to configure multiple authorization settings in a single request. The authorization is applied to the request through a separate module so the transformation won't change the request object in the editor.
Added response size limits. First limit renders a warning about the size of the message. The user can choose to render the view anyway. The other limit forces unprocessed ("raw") view of the response. This way it reduces chances of application hanging.
Removed "table view" from the response view. This module turned out to be very challenging to create and maintain. The final effect was a slow UI and not so good experience when working with the data.
Redesigned request actions. It has new actions (set variable, set cookie, delete cookie). Actions are also conditional. The user can set up a condition when the action is to be executed.
Added a new tab in the request editor: meta. It renders request meta data (name, list of projects, etc) for a saved request.
Removed ability to export to multiple folders in Google Drive (this was deprecated in Drive API).
The "detailed" URL editor now only edit query parameters
The request body editor now support different specialized editors and each of them stores own value. This means that when the user switch from "raw" to "Multipart" editor the multipart editor will restore previously used form
Themes manager now opens in a new window instead being part of ARC
Added status message about currently transported request. The transport library informs the application when the message is being transmitted, when headers are received, when response payload is being read, and when the load complete.
Added ability to send the request by pressing ctrl+Enter anywhere in the request editor. Similarly, the Escape key cancels the request.
Tabs in the request workspace now have flexible width. When more tabs is opened they shrink to accommodate all tabs in the current view.
Fixed tons of spelling mistakes :)

You can try the next version of the application today by downloading the alpha version. But, please, note that alpha version is not targeted for production. It hasn't been tested in the field and may contain undetected issues. If you find an issue, please, report it on the project's GitHub page, or by using application's "help" menu.

Advanced REST Client version 15 is released with client certificates

2020-01-29T23:35:00.000+00:00

Version 15 of Advanced REST Client has been released. You can install it from ARC releases page.

This release comes with a support for client certificates. Read more to learn how to use client certificates in Advanced REST Client.

Client certificates manager in Advanced REST Client

Client certificates is an authentication method that allows to select a certificate that will be used in the request to authenticate the user. The application uses this certificate at the initial handshake with the server. Without the certificate the server that supports certificate based authentication would reject the request with 401 status code (unauthenticated state).

The application now has a global certificate storage where all client certificates are installed. You can access it from main menu Request > Web session > Client certificates.

When adding a certificate you can choose from P12 (PKCS #12) and PEM (Privacy-Enhanced Mail) formats.

The P12 format requires to select a single file that bundles the public certificate and private key together. If the file requires a password then provide it when the certificate is imported. Currently there is no UI to check / edit password.

PEM import requires to provide 2 files: the public certificate file and the private key. Similarly to P12 you should enter private key’s password if required.

The request will result with internal error with status code 0 (zero) if the password is incorrect.

Once a certificate is stored in application’s data store it can be used with the request editor, specifically with authorization settings. After selecting “Client certificate” option in the authorization drop down, a list of installed certificates appear. Select a certificate you want to use with the current request. The application now handles the rest. When the “send” button is pressed the certificate is restored from the datastore, decrypted if necessary, and passed to the HTTP request engine for processing.

Other updates

Fixed issues with code snippets rendering (new lines at the end of the body)
Updated AMF parser to version 4
As a result of upgrading AMF parser also upgraded API Console
Added “--skip-app-update” and “--skip-themes-update” command line switches
Added auto switching to the dark theme when the OS operates in dark mode
Upgraded Electron version to 7

API Console version 6 is now released

2020-01-29T00:13:00.002+00:00

ARC's sister project, API Console - the API documentation tool, is now published with version number 6. It brings tons of changes and improvements. You can use API Console to document your APIs using API definition. Read more to learn about changes and features of API Console.
API Console is an application that generates documentation for an API from a RAML or Open API definition. It is done by generating an AMF data model thanks to the AMF parser or the “webapi-parser” module. The console is built on top of web platform APIs so it can be easily integrated with every web based application. It comes in two flavors: a stand-alone application and a web component. Depending on your use case you may use either of them.

The stand-alone application allow you to quickly generate documentation for an API and run it on a web server as a separate application. We are providing a CLI tool to generate the application from sources and a Docker image to simplify the deployment. The web component is to be used if you want to integrate the console with an existing application. This requires more setup and development process but allows for the most flexibility.

What’s new in version 6?

API Console is now WCAG compliant. During the development process we put a lot of effort into making sure that the console is accessible for users with disabilities. This version is tested via automated software and via manual testing.

The updated UI implements changes requested by our customers and the community. The navigation has a slightly different structure and now always renders a full path to the resource, even when it exceeds the size of a single line menu item. New examples and annotation widgets makes the UI more user friendly.

The request editor (aka “try it”) has been redesigned to simplify interaction with the API. It now only renders fields that require input from the user to make a successful request. This means, for example, if headers are not defined for an operation then they are not rendered.

With this release we added more security by sanitizing markdown data that are being rendered. Also, user input in the request editor is tested against invalid data.

Improvements to the console

Most improvements are related to performance. The size of the bundle has been reduced almost 4 times and now the bundled API Console weight is ~300KB. This speeds up console rendering time and improves memory footprint.

In the documentation view complex types are now hidden by default. This reduces potential crashes when the documentation has huge type declarations. In previous versions of the console this would lead to tabs crashing. Similarly, huge examples generated for such types are not highlighted by default. Previously it would require the browser to render unreasonable amount of markup that would hang the tab for minutes.

The console’s source has been rewritten to use the latest web standards which puts most of the work to the browser instead of JavaScript. This improves overall experience as the console runs smoothly regardless of the size of the API. The console still works with legacy browsers (down to IE11) with polyfills generated with the bundle.

Developer improvements

Being as close to standards as possible was rule #1 when designing architecture for API Console and the build tools. The console now follows Open WC standards for development and building processes. Application specific code related to the development and building process has been reduced to the minimum.

API Console has its own node module and CLI command to generate a bundle in a CI environment or manually. Besides that with this release we offer a Docker image that has bundled API Console, AMF parser, and a web server with it. As a developer you just need to pass an API project to generate data model from it and run the image on your Kubernetes instance.

Reasons to choose API Console

API Console is and will be in active development as it is one of the core Anypoint platform products while being an open source project. The console is tested in an enterprise environment and runs in both public and private clouds. It fulfills all requirements for an application to run in government’s cloud.

We have experience with building API documentation products supported by several years of development of API Console and other products like Advanced REST Client. We are open to suggestions and over the years we have listened to the voice of the community and our customers. Today we are proud of the final effect of our work and happy to share this experience with the community.

How to get started?

We’ve prepared a few demos with basic use cases for API Console. You can check it out at demo.api-console.io. For developers we have prepared a documentation page at docs.api-console.io.

Try API Console today and give us your feedback. We accept issue reports and feature requests on console’s GitHub page. If you are MuleSoft customer you can contact customer support and gives us your feedback directly.

Relation to Advanced REST Client

API Console is a sister project of ARC. It uses the same code base. The request editor (aka try it) is made from the same UI blocks but adjusted to consume AMF model. The response view is literally the same. Also, you can open an API specification in ARC and it renders API Console view embedded in the application.

Advanced Rest Client version 14 release

2019-10-18T20:22:00.000+01:00

Version 14 of Advanced Rest Client has been released. You can install it from ARC releases page.

This release comes with complete rewrite of code base and few new features. Read more for a full list of changes.

ARC version 14 main view

Highlights

Workspaces

ARC now support workspaces. It allows you to save current arrangement of requests to a file and share it with others. After opening the file in ARC it restores the same view and requests configuration.

This could be used for learning purposes. You can share your requests configuration and instruct your audience of how to test your API step by step (or rather tab by tab).

Workspace detail

You can add workspace description as Markdown, information about version, publication time, and the author.

Workspace detail editor

Request configuration

Use request configuration to override application or workspace configuration. Options defined on a request are applied to this particular request and won't affect other requests.

Request configuration options

At the moment you can change whether the request should follow redirects, request timeout, enable or disable SSL certificates validation, enable Node HTTP client (instead of ARC's), and to enable default headers (accept and user agent).

Image / PDF preview

The response view now shows images instead of binary string.

Response image view

When the response is a PDF file then it renders information about the file and allows you to save the PDF file to disk.

Default headers

ARC now allows you to add default headers: user-agent and accept to each request automatically. This way ARC behaves like cURL command and may help you test APIs that requires both values. The option is available in Settings panel > Request settings (global configuration) and in request config.

Code snippets in the request editor

Code snippets has been moved from context menu to request editor. It renders an example of running the request in various languages and frameworks.

New API Console

The API Console has been upgraded to latest version. It contains several design and technological changes. The API Console renders when you open RAML or OAS specification file in File > Open file menu option.

API Console in Advanced REST Client

Exchange authentication

Now ARC uses new authorization server for OAuth 2 connected applications. In APIs explore screen you can log in to your Exchange account to list your organization APIs.

Exchange API assets view

New stuff

Click on a link in the response view with CTRL/CMD key pressed opens new GET request in new tab
Now workspace has its own configuration file with set structure (see this document for more information)
Now it is possible to define variables on a workspace level. Workspace variables overrides application variables in case of conflict. With this release it is only possible to define variables in the configuration file.
Added export dialog to the request editor. It will now use the same UI as other parts of the application.
Adding configuration option to automatically add basic request headers: accept and user-agent. This way that application behaves like cURL.

Note, workspace configuration development is planned for several releases as it is a complex change in the application. Next planned change is to add variables editor for the request.

Changes

Web session URL input has been moved to the workspace instead of ARC application frame. It allows to configure the session URL per workspace.
Replaced default export file extension from "json" to "arc".
Redesigned application themes. Updated styles for Dark and Anypoint themes. Now theme definition is a regular CSS file.
Now changing a theme does not require application reload.
Moving code snippets from workspace to request editor.
Exchange search screen now is using new authorization server that fully support OAuth 2 protocol.
API Console has been redesigned. It also has new web components. The request panel has been simplified.
Variables list now masks values by default. It allows you to use the view when presenting to others.

Bug fixes

Content-* headers on GET request - now the application warns you before sending this headers with GET request. This headers can mess up the request on the server side.
Export to Google Drive flow. Authorization is fixed and the app is enabled to use Google Drive data.
Fixed export dialog in the history panel to include default file name.
Fixed z-index of the toolbar to restore variables overlay rendering.

We hope you will ❤ this release as much as we do. As always we are happy to learn more how you use ARC and how we can make it better for you. Contact us via GitHub or send an email to arc@mulesoft.com.

Advanced REST Client beta 14 release

2019-10-06T05:36:00.000+01:00

New beta 14 version of ARC has been released for testing.
You can install it from ARC releases page.

This release comes with complete rewrite of code base and few new features. Read more for a full list of changes.

The application now uses new web components that has been rewritten to comply with the final specification of Web Components. Also, in most cases, Polymer has been replaced with LitElement library.

New stuff

Click on a link in the response view with CTRL/CMD key pressed will open new GET request in new tab
Now workspace has its own configuration file with set structure (see this document for more information)
Now it is possible to define variables on a workspace level. Workspace variables overrides application variables in case of conflict. With this release it is only possible to define variables in the configuration file.
The application now allows to define workspace metadata (description, creation time, author info), export workspace to file, and open the file as a data source for the workspace. This allows you to create a workspace configuration (requests, variables, app-like configuration) and share it with others. This way, regardless of application configuration, you will have the same environment.
Added export dialog to the request editor
Adding workspace files history menu
Adding request configuration options panel in the request editor. Now some application configuration options related to request processing can be overridden on the request level.
Adding response image and PDF files preview in the response panel.
Adding configuration option to automatically add basic request headers: accept and user-agent. This way that application behaves like cURL.

Note, workspace configuration is planned for several releases as it is a complex change in the application.

Changes

Web session URL input has been moved to the workspace instead of ARC app. It allows to configure the URL per workspace
Replaced export file extension from json to arc.
Redesigned application themes. Updating styles for dark and Anypoint themes. Now theme definition is a regular CSS file.
Changing a theme does not require application reload anymore.
Moving code snippets from workspace to request editor.
Exchange search screen now is using new authorization server that fully support OAuth 2 protocol.
API Console has been redesigned. It also has new web components. The request panel has been simplified.

Bug fixes

Content-* headers on GET request - now the app warns you before sending those headers with GET request. This headers can mess up the request on the server side.
Export to Google Drive flow. Authorization is fixed and the app is enabled to use Google Drive data.
Fixed export dialog in the history panel to include default file name.
Fixed z-index of the toolbar to restore variables overlay rendering

We hope you will ❤ this release as much as we do. Try beta version and gives us your feedback.

What's new: ARC Desktop 13

2019-03-20T05:23:00.004+00:00

New version of ARC has been released. It was long lasted release containing tons of changes including: stability improvements, UI redesign, architecture redesign, security updates, and new features.

UI redesign

ARC pretty much is still the same application as it was with few UI tweaks.

Status bar (bottom of the request editor) has been removed. It didn't contain any relevant information. Save request button has been moved to request drop down menu (to the right to the send button). We all love to use shortcuts (ctrl/cmd+s or ctrl/cmd+shift+cmd) anyway!

Environment selector has been promoted to the application toolbar. Environment change effect whole application, not only particular request. It shouldn't be part of the request editor if there's more than one request in the work space.

Navigation changes includes:

Default screen is now work space screen; other screens are sub-pages
Access to web sockets is now in application menu > Request
Added button to refresh list in the menu
Navigation lists now comes with 3 size settings: default, comfortable, and compact (sounds like Gmail to you?). Change it in Settings > View

I also decided to deprecate "saved" requests. It is pretty much the same object as history entry but it has a name. This only make sense if you are working on API development in which case "project" would be more natural place for saving a request. As for this and next version this will work as was working since the beginning. After that I am planning to move all saved request to "default" project and remove this menu entry. You are welcome to join the discussion if your use case justifies keeping this feature. If there's no good reason to keep it I'll remove this menu and screen soon.

Security improvements

Trust is very important and therefore I've invested some time thinking about architecture of the application to make it reliable and secure.

The application will keep storing data in Chromium's internal storage (Indexed DB). This ensures data integrity and security.

As for changes in security area:

Disabled node integration in the renderer process - any data rendered in the response view won't affect your OS as it no longer has access to node APIs
Added content security policy to rederer process of the application - this ensures that only code intended to be part of the application is executed
Added preload script to be very specific about code that can be executed in the renderer process. This means that functions that has access to (for example) file system have to use an abstract layer (proxy service) to access any sensitive resources.

Request panel

The work space has been redesigned for performance. This version comes with complete redesign of creating, storing, and restoring request data. It has noticeable impact on how ARC renders UI by speeding up rendering of it.

When saving request you can now associate it with more than one project! It is a single object so a change to a request object on one project will change it in any other.

New (hopefully) cool feature is drag and drop of requests. It is experimental feature that can be enabled in Settings, in Experiments section. It allows you to move requests from menu to the request workspace and back (excluding history, there's no point of it). You can also move request between menu sections (for example from history to a project).

Tabs in the work space can now be reordered (experimental drag and drop feature has to be enabled).

Headers sets has been removed after very long trial as no one (according to Google Analytics) was using it.

Finally when the app is restored it also restores latest responses.

There's much more changes to the application than this. See full changelog at https://github.com/advanced-rest-client/arc-electron/releases/tag/v13.0.0

Happy RESTing!

Deprecation of xml-viewer component

2019-02-14T20:52:00.001+00:00

Advanced REST Client and API console uses this component to render XML data. We want to retire this component as it does not give any advantage over using Prism library (right now this library is being used to render other types).
The component also causes problems when integrating it into other systems because it uses web workers. I have received many requests to remove use of web worker. My response is always: no data parsing in main thread process as it may cause the UI to hang. Prism also uses web workers but at least we will have one thing less to be worry about.

The "response-body-view" and "response-view" components that uses this component will be changed around July 2019. After this date new version will be released without additional support for XML responses other than Prism highlighting.

See this intent to deprecate here and comment if you'd like to take a part in the discussion.

API components now support v1 web components spec

2018-06-04T19:52:00.001+01:00

After a few months of preparation I am proud to announce that more than a half of web components that are part of API components ecosystem now support version 1 (stable version) of Web Components specification. In short, this means native support on all browsers without polyfills.

As you may know already, ARC's API components were used to build MuleSoft's (now SalesForce) API console. Earlier this year API console was scheduled to upgrade to use new data model generated by AMF - the AML Modeling Framework (AML stands for Anything Modeling Language). Both AMF and AML was developed by MuleSoft last year. It allows to create common data model for all API specs (or anything else for that matter).

This change required major change in the components to support new data model. I saw it as an opportunity to upgrade the components from v0 of the Web Components specification (supported natively by Chrome and Opera only) to final specification. Now all components that are part of the API console are upgraded to the new specification and then some that are used in Advanced REST Client. Release of new API console is planned later this month. Currently it is on GitHub on the preview branch. In time all API and ARC components will be upgraded to version 1 of the specification.

But what does it mean to you?

If you just use ARC or API console - nothing at all. Well, there's a lot of design improvements in API console so general UX is just better.
However, if you are a developer and you work with API testing or API documentation you may leverage the power of API components in your projects.

First of all, API components are open source and free to use to everyone. Then it has support of MuleSoft (well, SalesForce since last Friday). We are using API console in our internal products so it has to pass the same tests (integration, unit testing, security) as any other enterprise application offered by MuleSoft. Finally, since latest major update to the components they can be used in any web environment where majority already support Web Components specification natively.

API components offer a number of UI and logic components to build API testing applications. But that's not all. API components can also render a documentation for an API using AMF data model (generated json/ld model). This means you can use, for example, the documentation component (api-documentation) and include it into your website or web app to render documentation for your API.
Soon I'll publish official documentation for using the components. For now you can follow instructions from Polymer documentation as it uses the same development process.

I'll be happy to fear from you what are your use cases and how I can improve API components. But not only the components but also API console and Advanced REST Client.

Automate Your Work With Request Actions

2018-02-13T09:00:00.000+00:00

We recently held an internal MuleSoft hackathon and, as a result of that event, I am excited to introduce a new feature in the Advanced REST Client (ARC): Request actions.

Request actions allows users to define a logic that is executed when the response is ready. Currently, users can assign value to a variable or store the variable. However, the variable can be extended to other use cases.

Request actions can read values from any part of the request or response. When defining actions, users can define a path to a specific value in the URL, in headers, or in the body. They can assign or store this value as a variable.

Use case: OAuth 2

In order to get an access token from the authorization server, we will:

Sign in to the authorization server to get auth cookies
Create a request to the authorization endpoint
Create an action to store the token from the request URL to a variable

First, the authorization server will display the login page if you are not signed in to your account. To skip this step, we will use the Web Session feature to Log in to a web service. You can access this feature from the Request menu.

The URL can be either the authorization server’s login page or the full OAuth2 authorization URL, which should include all required parameters.

This allows you to log in to the service. Then, ARC stores authentication cookies and uses them when requesting the token.

After you log in, we are ready to receive the token automatically. Use the full OAuth 2 token request URL as a request URL. It should look similar to the example below:

domain + auth endpoint + (query parameters): redirect_uri + client_id + response_type

This is the easiest scenario possible. Your example may contain more query parameters (like state or client_secret).

Here is an example of the authorization URL (please note that these are not a real parameters):

https://auth.domain.com/accounts/oauth2/authorize?redirect_uri=https://auth.advancedrestclient.com/oauth-popup.html&client_id=a12oZqF9I07AZMJec&response_type=token

Note the redirect_uri parameter. You have to set the redirect URI in your OAuth 2 settings to https://auth.advancedrestclient.com/oauth-popup.html. Otherwise, the authorization server will not allow you to redirect the request and receive the token.

If you make the request at this point, you will be redirected to the response page. Open response Details, and then click on Redirects to see that the token is in the "hash" part of the request URL.

To extract the access token value, we will create an action that reads data from the response URL and then assigns the value to a variable called "accessToken".

We will use the response URL because it contains the final URL after last redirection. The URL should contain the access token in the hash part of the URL.

If you use the "hash" property in the Path to data input field, the application treats it as a query parameters string. It will only work if the hash data is formatted as a query string.

Now, when you call the endpoint it will temporarily assign the token value to the "accessToken" variable. ARC will use this value until the application restarts or until a new value is assigned.

Finally, after the above step, users can leverage the stored value in the request using variables.

Adding a condition

You can also instruct ARC to perform the action if certain conditions are met. You can define conditions in the Request action editor by clicking the "Add condition" button.

The process is similar to the Request action. You have to specify the path to the data and then specify a logical condition like equal, greater than, contains, or any other operator. Finally, add a condition value which represents the value that the app will use to compare the value from the request or from response objects to the value itself.

The action is executed only if all conditions defined for the request are met.

Both Request actions and conditions give you a powerful tool to automate tasks like requesting an authentication token or creating test resources.

You can read detailed documentation at ARC wiki pages. You will find detailed instructions for constructing the path and examples of how to use the tool.

Download the desktop client

Ready to get started? Go ahead and install the Advanced REST Client! Please note that only the desktop client can execute Request actions.

RAML landed into Advanced REST Client

2018-02-12T19:38:00.000+00:00

I am excited to announce the new Advanced Rest Client (ARC) support for RAML specifications. RESTful API Modeling Language (RAML) makes it easy to manage the whole API lifecycle - from designing to sharing APIs. With version 12 of the ARC desktop app, you can now open RAML files and display their API documentation using MuleSoft's API console.

The console allows you to read documentation for all endpoints and methods defined in the API spec file. It also allows you to make a test request to any selected endpoint. The request data is pre-populated with default values as well as examples from the RAML file - making it easy to run test requests.

The console also understands the security limitations of the API and makes it easy for users by requiring them to only fill the required fields in order to make a successful request.

Anypoint Exchange

ARC allows users to query Anypoint Exchange for public API spec assets. Anypoint exchange is a service that offers API assets storage, sharing, and management. Users can log in to their existing account to get the list of their private assets.

Then, in just one click users can download and open the RAML file in the app.

Only in desktop client

Ready to get started? Go ahead and install the Advanced REST Client! Please note that only the desktop client can read RAML files and connect to Anypoint Exchange.

Using Polymer web components in React application

2017-12-05T02:47:00.002+00:00

Today I've released a first version of the node module to wraps Polymer powered web components into React component.

The wc-reactor module takes a web component declaration (source code) and uses Polymer analyzer to get information about the component. Finally it creates a bridge between React and web platform so you can use any Polymer web component in a React application as if it is a React component.

By default the module generates the interface for every web component defined in the source file and its dependencies. The input file can be Polymer build file (bundle file that concatenates many web components). In that case all components are analyzed and wrapped into React components.
You can tell the module to limit number of generated wrappers by specifying a list of web components names that will be used to generate the wrappers.

Example usage

const reactor = require('wc-reactor');

reactor({
  webComponent: 'bower_components/paper-input/paper-input.html',
  dest: './out',
  bundle: false,
  reactComponents: ['paper-input']
});
.then(() => console.log('Build complete');

This use of the module generates PaperInput/PaperInput.js React component that is the interface for React application. The interface allows you to set properties on the web component, handle custom events by setting event handler functions as the component property and call public API functions.

/**
 * Handles value change event of the paper-input web component
 */
_onValueChanged(newValue, e) {
  e.preventDefault();
  console.log(newValue);
}
 
render() {
  return (
    <paperinput label="User name" name="username" onValueChanged="{this._onValueChanged}/" required="{this.props.required}">
  );
}

Note that you still have to import the web component into your application. This module does not recreates the web component for React but creates the interface for React application to communicate with web component.

Bundling ARC web components and generating React components

Another module released today is the arc-components-builder that creates a bundle file of web components (single import file). The module can be used to create a build of ARC or any Polymer powered web components. It handles dependencies installation, source analysis and bundling using Polymer tools under the hood.
This module also uses wc-reactor to generate a React interface for the build file.

const builder = require('arc-components-builder');
 
builder({
  // Any web component, it can contain version declaration
  webComponents: [
    'PaperElements/paper-input#1.0.0',
    'vaadin/vaadin-button'
  ],
  // Any ARC component, it also can contain version declaration
  // but doesn't require Github path
  arcComponents: [
    'content-type-selector',
    'paper-combobox',
    'headers-editor',
    'http-method-selector',
    'url-input-editor'
  ],
  // Creates React wrapper
  react: true,
  // Create React interface for the following components only.
  reactComponents: ['url-input-editor']
})
.then(() => console.log('Build complete');

This command creates a bundle import file of following components:

paper-input
vaadin-button
content-type-selector
paper-combobox
headers-editor
http-method-selector
url-input editor
... any any dependency of this elements

Finally it creates a React wrapper for url-input-editor (as React's UrlInputEditor component).

The output directory contains import.html file with the bundle of web components that should be included into the application. It can be done manually by referencing the file.

<link rel="import" href="import.html">

For react applications the wc-reactor module generates a helper file that contains functions to add a polyfill script and to import link declaration to your document:

import { polyfillScript, componentsImport } from './WebComponentsImports';
var doc = `<html>
  <head>
    ...
    ${polyfillScript('/base-path')}
    ${componentsImport('/base-path', 'import.html')}
  </head>
  <body></body>
</html>`

I'll be happy to hear a feedback from you. If you have an idea or a use case that is not covered by the module, please leave a comment or create a feature request on Github.

Moving Data From Advanced REST Client Chrome Application To The Native Application

2017-11-10T20:38:00.001+00:00

If you are ready to install new Advanced REST Client native application probably you would like to move your data along with you.
Unfortunately there's no automatic way to move the data from Chrome application to new native application. This has o be done manually by exporting the date to file (or to Google Drive) and then import it in the new app.

Let's start with installing Advanced REST Client native application if you haven't done that already.

Install

After new application is installed go to ARC Chrome application and export the data.

In the top right application menu select Import and export data.

The import / export panel is displayed. By default all data are selected. You can choose whether some part of the data should be excluded from the export. Click on Prepare data button to compute export object from the datastore entries. Depending on the amount of data and speed of your machine it may take a minute.

When the export object is ready choose export destination. The easiest one is to export to file. Save the file on your local disk.

Now open the new Advanced REST client native application. In the application menu select File > Import data.

Similar to previous application the import / export panel is now displayed. Select Open from file to read exported file.

Select the file

And import previously exported data.

This is the only way to avoid data loss when Chrome team will disable Chrome applications.

You can still use the old application but to transfer newly created data to the other application you will have to repeat this procedure.

ARC components in Mulesoft's API Console

2017-11-07T19:56:00.000+00:00

I am proud to announce that web components that are used to build ARC are now also used to build Mulesoft's API Console.

MuleSoft's API Console is a full-fledged API documentation tool that generates mobile-friendly web documentation based on RAML (Restful API Modeling Language) documents. It is an open source, community driven application that can be easily adjusted to any environment.

Background

While working on atomizing Advanced REST Client to a set of web components internally in the company we've realized that both products can share the same code base. So over a year ago I've started working on new version of the API console. The task was to create a best in class usability for API documentation tool. That includes mobile friendliness, ergonomic design, ease of reading documentation and learning the API structure. From a developer standpoint API console should be easy to use as a standalone application ready to run on a web server but also as a embeddable HTML element that can be added to existing products (like existing web pages with API documentation).

The result

API console is a web application based on web components standard. Therefore it can be used in any web environment and can work with any web framework (though some frameworks - like React - may require additional customizations). We've created a set of tools to make it even easier to build the API console from a RAML file. Our CLI tool can be used to generate production ready standalone website with API documentation or to generate development preview of the documentation while working on RAML. There also is the api-console-builder npm module that can be used in node environment to build the same API console.

Try new API console and design your APIs with RAML. I'll be happy to hear a feedback from you.

New Advanced REST Client native application - install today

2017-11-05T19:33:00.001+00:00

New version of Advanced REST client is ready! It is installable native application available in all major platforms:

- Windows (32 and 64 bit)

- MacOS

- Linux (deb and rpm)

You can install it from install.advancedrestclient.com. Do it today and move your data from legacy Chrome application to new native application.

Changelog v11

- Tabs in the request panel are finally there. No need to open many windows of the application (though you still can)

- Automatic updates that can be turned off if necessary

- Cookie manager - now you can create / edit / delete cookies in the application. Cookies are applied to matching request domain and path

- Web session setup - open URL in app's internal browser to create a web session. Cookies from this session are automatically applied to the request

Termination of Chrome Apps - ARC native application

2017-10-11T21:52:00.001+01:00

Some time ago Google decided to terminate support for Chrome apps in Chrome. Therefore Advanced REST Client will be removed from Chrome.

For last few months I've been preparing the app to this by externalizing parts of application code to a number of web components. Web components based on the native platform helps me build ARC as a different applications running in different web environments (web, node, Chrome / Firefox extensions etc). Last week I've moved rest of the application logic to external component. This enabled me to work on alternatives for ARC as a Chrome App.

Now I'm proud to announce that currently I'm finishing testing Advanced REST Client native application. The app is available on all major platforms:

- Windows (32 and 64-bit)
- MacOS
- Linux - as a rpm and deb package (both 32 and 64-bit)

Because the application is still being tested I am not going to publish installation URL to you at this time. When I'm sure that the application is bugs free I'll update the Chrome Application with information about migration path and post another article on this blog.

Action to be taken now

Because Chrome Apps will be forcibly removed from Chrome your data will disappear as well. To not lost your data please use the export option today to export the data to a file or to Google Drive.

Note: Native application has different Google's Client ID and therefore it is not possible to open Google Drive file from the application ui. You'll have to authorize the application within the app UI and then go to Google Drive web app and choose "open with" option for the file.

Also you can export the file to Google Drive and later simply download it and import as file.

The timeline

In a month (or so) from now Chrome applications will be removed from Chrome. Replacement application is ready but it's not fully tested. Also it still need a code verification certificate (I am working on this issue) before stable release.

In 2 weeks time new application should be released in stable channel. At the same time Chrome application is released with information about termination of Chrome apps and path to migrate.

In a month Chrome apps are terminated and hopefully all users have been migrated to new application.

See you in the new app!

New design proposal

2017-02-22T19:07:00.001+00:00

Recently I've started working on a new design for ARC. It was caused by necessary changes in the body panel (especially multipart form).

I've come up with the following:

More of the mockup: https://xd.adobe.com/view/9fefbc1d-18fa-43e3-afb5-7b8af5efe586/

I am really interested your opinion. So please, if you have any thoughts about it, leave a comment below or commend directly on mockup page.

Thanks!

Web Components @ scale - my topic at the DevFest 2016 conference in Warsaw, Poland

2016-11-23T13:43:00.001+00:00

Hi developers.

I'm proud to be a speaker at the DevFest 2016 conference in Warsaw, Poland.
The conference is this Saturday in Praha Cinema. My topic will be about building web applications that scales using web components. I’m going to talk about development workflow with web components, using platform over frameworks and how Polymer 2.0 is shifting from being framework to being support library for web components removing all framework alike functions.

The Advanced REST Client application is now a Polymer - or rather web component - application. For last year I managed to rebuild the app from GWT framework to web components. I have also an experience in other apps build with Polymer. But the case of ARC showed me that wrong architectural approach - even with web components - may end up with building another monolith that just use another framework. But web components are made to be a real building blocks of modular application.

If you are in Poland at the time I strongly encourage you to be at the conference. Many great speakers are managed to be there and many great talks are being prepared. If you will, just say hi to me :)

See you at DevFest!

PouchDB read optimisation - reducing time of data queries

2016-11-02T19:15:00.003+00:00

Recent ARC version has so called API assistant. It's a helper program which queries history data for relevant information when the URL or HTTP method changed. It reads history of requests made to particular method (meaning endpoint and method) and analyse the statistics data about this method like connection time or response size.

Recently I was asked how it will behave when the app stores a lot of data. I mean hundreds of thousands of records. Then it occurred to me that I haven't performed test for this amount of data. It started a series of changes in the code of the assistant which finally allowed me to shorten database query time by 98.52%!
But lets start from the beginning.
The app uses PouchDB wrapper for the IndexedDB database. Every time a user make a request in the app the request, response and some timings data are stored locally in the data store. So far this data was never really used. But now the assistant make a lot of use of this data.

This is how computed assistant report looks like:

The API assistant

The data are computed across all the history data. It can be few records but it also can be a lot of data gathered for months or years.

Initial tests showed that the query time do not influence app performance and it's still fast. But then I've generated 300 thousands additional records and the app started to work little bit slower. I measured that average data query and processing time for data was ~35 seconds. That's a lot of time and it was unacceptable for the app.

The cause

As mentioned earlier the app is using PouchDB database wrapper for IndexDB. It's a nice library but it turns out that it may also be slow even when working directly on keys. When getting a record from the datastore using PouchDB it looks for a key, then in the metadata values it checks if the record is deleted or not (PouchDB doesn't really delete data because it's need it for replication, it only marks it as deleted). Then it need to find latest review of the record (the _rev parameter) and finally read the record associated with the key. Rev search part is required because the PouchDB keeps history of changes which is required for replication with the remote database.

The data structure

First step for optimisation was to use proper data structure. Fortunately I make a use of keys in IndexedDB. Many developers (including me in the past) don't really use keys to find the data. It appears, however, that keys are excellent tool to query IndexedDB really fast. And to sort data without calling sort function on the result list.

The app is using the following structure of the history data key:

URL encoded request URL + "/" + HTTP method + "/"  + generated UUID

Why this structure? With this keys I can open cursor on the data store keys and iterate over keys only without event loading and reading the object associated with the key. Below I'll show it on the real code.
The UUID is attached to every request or else the record will be overwritten when saving new history object for the same URL and HTTP method which would defeat the purpose of the store.

The solution

I'd like to worn you that this will work on data that aren't suppose to change over the time. It doesn't care about the revision system of PouchDB.

First step to optimise the query time was to use... raw IndexedDB instead of PouchDB wrapper. It may sounds silly, because we are using wrappers to not work on the raw IndexedDB, because it's not easy, it is not supporting promises, querying IDB is really hard and you may find 10 other reasons for not using it without a framework. In this case, though, it was the only thing I could do to get the data out really fast.

Algorithm for the database query is quite straightforward:

Compute the "queryKey" whis is beginning of the key consisted with URL and HTTP method that we are looking for (the encoded URL + "/" + HTTP method part)
Open a cursor (with value) with key range defined from the queryKey on the document-store store
In the success callback function check if value's deletedOrLocal property equals zero

If yes, append result's seq property to the results list

When all data are ready then query the by-sequence store and get data for each key
Compute stats data

You may notice that step 4 can be included into step 3. Then using the same transaction you could take a data from the other store. I've tried this, measured impact ono the performance and in this scenario read time doubled! Somehow, when using two different transactions with single store opened within the transaction it double speed up the read time.

Lets jump to the code.

// The namespace
var processor = {};
// Open the database
processor.getDatabase = function() {
  return new Promise((resolve, reject) => {
    // In ARC the store is called history-data
    let request = indexedDB.open('_pouch_history-data');
    request.onerror = function(event) {
      reject(event);
    };
    request.onsuccess = function(event) {
      resolve(event.target.result);
    };
  });
};
// Query keys for related data
processor.queryKeys = function(db, url, method) {
  return new Promise((resolve, reject) => {
    // This is where PouchDB stores keys defined in the app and related metadata. 
    // It also stores the sequence number which is a key to the data stored by the app for given key
    let transaction = db.transaction(['document-store'], 'readonly');
    let objectStore = transaction.objectStore('document-store');
    // Creating beginning of the key to search for.
    let key = encodeURIComponent(url) + '/' + method + '/';
    var keyRange = IDBKeyRange.bound(key, key + '\uffff', true, true);
    let request = objectStore.openCursor(keyRange);
    let keys = [];
    request.onsuccess = function(event) {
      let cursor = event.target.result;
      if(cursor) {
        if (cursor.value.deletedOrLocal !== '0') {
          // This record is useless
          cursor.continue();
          return;
        }
        // The `seq` keeps a reference to the by-sequence store where the final data are kept
        keys[keys.length] = cursor.value.seq; 
        cursor.continue();
      } else {
        // ready to continue
        resolve(keys);
      }
    };
    request.onerror = function(event) {
      // Because data consistency is not very important here we can do nothing.
      // Other apps could actually report an error.
      console.error(event);
    };
  });
}

Querying by the key is very efficient. This part of the app, no matter the database size (at least sizes I checked so far) always took couple milliseconds to finish! Notice that in this time I've completed a query for particular URL and HTTP method!
It is possible because I coded key with the formula described above. The rest is just a native KeyRange and cursor.

var keyRange = IDBKeyRange.bound(key, key + '\uffff', true, true);

The whole magic is happening here. The \uffff is added to the end of the upper boud of the key range because IndexedDB is indexed in lexicological order. It means that if you want to query for data from some string value up to any character after this string you have to use highest character value (in the UTF table) which is the \uffff character. IndexedDB is optimised to run queries like this. If I'd use auto-generated keys or any other key structure this wouldn't be possible and I would need to query all data in the database and perform manual search. And this would be very expensive.

Finally the queryKeys function returns a list of sequence numbers, which in PouchDb is a key for the by-sequence store, where the final data that I'm looking for are kept.

processor.readHistoryData = function(store, seq) {
  return new Promise((resolve, reject) => {
    let request = store.get(seq);
    request.onsuccess = function(event) {
      resolve(request.result);
    };
    request.onerror = function() {
      resolve(null);
    };
  });
}
processor.getHistoryData = function(url, method) {
  var startTime = performance.now();
  var db;
  return processor.getDatabase()
  .then((_db) => {
    db = _db;
    return processor.queryKeys(_db, url, method);
  })
  .then((list) => {
    if (!list || !list.length) {
      return [];
    }
    // Second transaction I mentioned earlier
    let transaction = db.transaction(['by-sequence'], 'readonly');
    let store = transaction.objectStore('by-sequence');
    return Promise.all(list.map((i) => processor.readHistoryData(store, i)))
    // Clean up possible errors. Your app can actually collect information about the errors
    .then((list) => list.filter((i) => i !== null))
    .then((list) => {
      list.sort((a, b) => {
        if (a.created > b.created) {
          return 1;
        }
        if (a.created < b.created) {
          return -1;
        }
        return 0;
      });
      return list;
    });
  })
  .then((data) => {
    let execTime = performance.now() - startTime;
    return {
      data: data,
      time: execTime
    };
  });
}

The readHistoryData function just reads the data associated with given key. It's the most natural way to do it in IndexedDB. What's interesting is that I don't create a transaction for each call of this function. I rather use one transaction and I'm passing it as an argument to the read function because it's faster.

The getHistoryData function if the one to call to get the data. It contains a sequence of events to query and read the data. The by-sequence store is the store where the data the app needs are kept (in PouchDB model).

One more thing to consider. I use The sort function to sort data from the oldest to newest. It's actually a room for improvement here. If the key instead of UUID contained a timestamp of the request then I wouldn't need to sort the data. Remember lexicological order? The database would just return already sorted data by time. Right now it's a few milliseconds added to the the overall process time so it's not important issue but in the future I would change it.

The improvements

Like I said in the beginning I was able to reduce query time by 98.52% just by bypassing PounchDB and using raw IndexedDB to query this particular data. This are the result's of measuring both implementations.

For 30,934 records in the datastore:

PouchDb query (ms)	Raw IDB query (ms)
9984	170
9500	204
9715	199
9537	195
9665	172
9433	154
9501	207
9739	167
9719	212
9685	181
9599	176
9665	181

Last row is a median for the values. In this case the improvement was -98.13% of query time.

For 160,934 objects in the datastore:

PouchDb query (ms)	Raw IDB query (ms)
88479.58	662.49
53449.78	790.735
53165.36	741.625
54344.375	877.285
53601.495	815.605
53140.32	810.6
54249.165	841.805
53752.095	728.825
53533.885	712.17
53565.16	691.475
53838.635	833.09
53601.495	790.735

The improvement is -98.52% of query time. That's a lot!

I hope that you've found this article helpful and you'll use this technique to improve a performance of your app.
The most important thing here is to remember that you can use IDB keys and they should work for you. IDB doesn't care if the key is a string, number or object. But you should care.

Full code is available on my GitHub: https://github.com/jarrodek/ChromeRestClient/blob/develop/app/elements/request-stats-analyser/request-stats-analyser.html
It's embedded a the web component which creates a web worker instance from the template content and run it in separate thread so main UI is not affected by the database query and later by data analyser.

Variables and environments in the Advanced REST Client

2016-11-01T15:28:00.003+00:00

New release of version 8 brings new feature to the app. It's a variables and environments editor. It is an extension to already existing "magic variables" feature introduced in 2012. Earlier you could set a limited number of keywords to generate numbers in any part of the request. Now own variables can be defined in the app and assigned to environment. During the request the value of the variables will be applied in place where the variable was used.

Why to use variables and environments?

Lets say you have different environment for your app: development, staging and production. On this three servers you need to pass different - for example - authentication parameters. You can define three environments in the Advanced REST Client (one for reach real environment of your app) and create a variable that will contain a value that needs to be passed to this particular environment. OAuth access token for example. Then you use this variable in the suitable place (URL or headers for example) and during the request this variable will be replaced with proper value.

Consider following examples.

Here, the authToken variable has been defined for the staging environment which is selected right now. We'll use this variable in the URL:

In the response panel, in the request headers you'll see that the request was altered by the app before sending it to the server:

The same will happen if you put a variable anywhere in the headers and payload panels as well.

Variable definition

Variable is always a string. Even if the type can be numeric it's always a string. And it's a good thing actually because you don't need to care about types in the app.
You can define a variable value as a string, concatenation of string and other variables or concatenation of variables.

Consider following example:

Request headers:

And the response:

The theHeader value is a concatenation of both secret and clientId variables and predefined variable now which inserts current time.

There is a limitation, though. You can't use a variable in the other's variable value if this variable has already a concatenation of variables. It will produce an error in the request.

The wontWork variable will produce following output:

It's a safety mechanism to not create circular object dependencies which will create infinite loop and eventually will crash the app because it will run out of memory. Therefore only one level of variables are allowed.

Disabling variables

Single variable can be disabled by unselecting the checkbox next to it's name.

You can also completely disable variables in the app settings if you don't want the variables to be applied at all.

Future of the variables

Right now you have to assign a value of the variable manually. And also you have to know the value at the moment. Future releases of the Advanced REST Client will have this feature more advanced by adding scripting environment where you'll be able to assign value of the variable depending on the response for selected or any request. It makes authorisation and token exchange flow much easier to manage in the app.
Next step will be to add string and numbers manipulations functions to the variables so if needed you'll be able to - for example - subtract a token value from the response header of calculate a value of the variable depending on other variables.

P.S.
At the moment when this blog post has been published, version 8 of the app is in beta channel. You can test this and report early feedback. It will be released into the stable channel in coming weeks.

ARC version 8

2016-10-26T13:57:00.000+01:00

Recently I've published an update to the beta channel of the Advanced REST Client. It is a version 8 of the app.

This update introduce many changes in the background so it is a starting point for father development.

Database structure

First of all the database structure completely changed. Old database and data in it are intact and will just stay there for some time. At leat until I'm sure that everyone migrated the app to new structure.

The app has migrated to use PouchDB as a wrapped for IndexedDB. It gives powerful options especially in terms of data integrity management (thanks to its revision system) and synchronizations with external databases (which is not yet in the app but it's in the roadmap).

But the man reason for database structure change was performance. Previously, when querying the history data to build a listing view it was getting out all objects from the datastore (yes, every request object with it's history of calls which includes request and response data) just to show time, name and method. It was very inefficient and was slowing down the app drastically.
New database structure is more complex and is using different databases for each object type but it makes performance much better.

History analysis

When you making a request the response is saved to the database. So far it was never used and I had an issue on issue tracker marked as "do something with it in the future". So finally I did something with it.
When you open a request (from history or from saved data) or just enter an URL a new process will start and will search the database for history of requests made to this endpoint. A small button in the bottom right of the app appear when data are available to open data explorer.

This data explorer shows charts for:

Time data

Response time as an overall time need to perform full request cycle
Connection time - time needed to to make a connection to remote server
SSL negotiation time (only for https endpoints) as a time needed for SSL negotiation
Message sent time - a number of milliseconds needed to transport headers and request body to the remote machine
Time to first byte - as a time between finished sending a message and receiving first bytes of data. You can say is that it is a server request process time
Data receive time which is a time measured since first byte arrives until connection was closed or last message byte was read.

All times are in milliseconds. Note that this data are not available for "XHR requests" (if you use this option to make a connection).

Size data

Request headers size - size of the HTTP message (headers part) sent to the server
Request payload size - size of the body data send to the server. This data are not available for GET and HEAD requests
Response headers and response payload size - similar to above but as the data received from the server.

Both size and time data has calculated median for each chart so you can see what's abnormal and when did it happened.

Last chart is a histogram of the response status codes. It shows how reliable the endpoint is in a reference to responding the same way all the time.

Other changes

Projects in form as they are right now are now deprecated. New projects will be implemented in next release. You can check out this prototype to see proof of concept of the new app.

The app now have a status bar. Besides actions for data explorer and other planned actions it also contains a status message for the request. You normally won't need it. But when the connection or server is really slow you'll see at which part of the request the process slows.

If you are using ARC exported files in some other way than importing it back to the app you'll have a problem because file structure has changed.

CTRL/COMMAND + S shortcut saves current request in the database by default without showing save dialog. At least if the request was previously saved. You need to click on the save icon on the top bar or use CTRL/COMMAND+SHIFT+S to open "save as" dialog.

Rest of the changes are minor bug fixes reported by the users. Issue tracker is the fastest way to stay in contact and request a feature or file a bug report. I check if even more often that an email.

Beta trials will end in coming days (depends on if I or anyone find a really annoying bug) and then the update will be pushed to the stable channel.

Beyond Chrome Apps - ARC as a native app

2016-09-26T13:55:00.000+01:00

Hi developers,

For some time now I am working on completely new version of the ARC. Don't worry, it will be the same good and simple tool for testing API calls. However a lot will change in the background. It will allow me to move the app to new platforms other than Chrome ecosystem.

According to app's roadmap ARC will be re-modulated and each part of the app (as a web component) publicly available on GitHub. It helps both the app to transform into new set of tools available everywhere and openness so everyone can use this web components in their projects. This is my contribution to the development of the open web and I deeply believe that this will help in overall web development.

You may already heard that Google will discontinue Chrome Apps in some time. Advanced REST Client will be available on other platforms when it will happen. Additional tool will be released later this year alongside with other platforms releases to move your data from Chrome app to your new favourite version of the ARC.

Currently planned new versions are for:

Windows 7 and later (32- and 64-bit)
MacOS (min version 10.9, 64bit)
Linux (32- and 64-bit)

Ubuntu 12.04 and later
Fedora 21
Debian 8

This list will change in the future by adding more implementation. However this is a base for moving the app from Chrome ecosystem.

Frequently Asked Questions

When Advanced REST Client disappear from Chrome Web Store and Chrome?

According to Chromium blog posts Chrome Apps will disappear from CWS listing in second half 2017. In early 2018 Chrome apps won't load in Chrome.

This gives about 1,5 year to move ARC to other platforms.

What about my data saved in ARC?

There's no seamlessly way to transfer data from Chrome App to other app. Arc already have import / export function so probably it will be used to transfer data between apps. However it will require user action. ARC will provide additional tools to transfer data between Chrome App and other versions.

Will ARC work the same way on other platforms?

According to my current knowledge there's no reason to assume that there will be a compromises while moving on different platforms. But remember that the ARC won't be part of the Chrome platform anymore. Sessions authenticated in tabs will not work in ARC without additional extension installed. Also cookies information won't be available until additional extension is installed.

When new releases will be available?

In coming months. ARC internally is not a small project and it is required to rewrite most of the code to work as a separate web components. Once new releases will be ready you'll be notified in the app, on this blog and Google Groups for beta testers.

There maybe more questions from you and I'll be happy to answer them. Use comments section below to ask them and I'll answer it as soon as I can.

Thanks for using the app and happy RESTing

Prototype testing - invitation to the usability research

2016-09-19T09:00:00.000+01:00

I'm happy to announce that we are ready to conduct a user research on a prototype of new Advanced REST Client.

List of changes is very long. Starting from general UI redesign to change in basic functionality.
The most important changes are:

new projects will support RAML (RESTful API Modeling Language) standard. Users will be able to import RAML file and use it as a "project". RAML contains API definition with the documentation that will be displayed alongside with the RAML request (new view in the app) and in project documentation page

history / saved / projects panels has been redesigned and now all of them are combined into one exploring / searching panel. History and saved data are accessible through URL panel (when the value is empty). Searching the history is possible by entering a non URL like query into the URL field
the app will have more authorisation settings and accessible from new Authorisation panel in the request form. Users may choose if they want to enter the authorisation data manually (headers editor) or setup header using new panel
environmental variables now can be defined by the user and added to the request along with old predefined variables (random and now functions). Variables will support basic arithmetical and string operations (Math and String functions).
Variables are enclosed in an environment, environments can be changed and managed from the request panel
New JSON/XML editor for the payload editor. The prototype contains JSON editor only but XML is based on the same principle.
Users are now able to define a header sets and use them later in a request

This is only a prototype but it is a direction where the app will be developed in coming weeks.
Because ARC is a community driven project we'd like to invite you to the prototype testing. You're feedback is really valuable and may help to made a final decision about app development and design. If you are interested in prototype testing please visit https://jarrodek.github.io/arc-prototype/arc-prototype/app/ to see the prototype.
To give your feedback simply fill up this form: https://insights.hotjar.com/s?siteId=284832&surveyId=13542 or give an open feedback on issue tracker here: https://github.com/jarrodek/ChromeRestClient/issues/796

The testing will end very soon so there's no much time to conduct the test.

Also, we are looking for people who will take a part in the usability research for ARC. The remote user research will be conducted in the coming weeks and will be a recorded session of a participant performing given tasks in the app. It will be conducted on participant's computer at a convenient to her / him time because the research is not moderated.
If you'd like to take a part in remote user research, please fill in this form: https://docs.google.com/forms/d/e/1FAIpQLScgEeqgIILSe4sOPRLtPU2mJNf6Hb-123GiTtSnWA01zK4zOA/viewform and we will contact you shortly.

Thanks!
Pawel Psztyc & the ARC team