RAML landed into Advanced REST Client

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.

ARC version 8

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.

Prototype testing - invitation to the usability research

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

Join Advanced REST client beta program

Hi developers,

In the coming weeks I’m planning to release a new version of the app. I would appreciate your input on the changes I’ve made and help in finding bugs before the final release. Take part in the app development and become a beta tester for the new ARC beta channel.

ARC reborned

Hi developers,

For past 2 years I haven't been very productive developing the app. There was a lot of things going on in my life (work, study) and eventually I haven't got time to develop the app. Well, this is about to change.

For a last two months I moved the project forward. Source code is now available on GitHub and all issues has been moved there as well. I started working on app's improvements and there is a lot to do. So probably you'll be happy to hear that I'm developing the app full time now!

Encoding drop down removal from the app

Hi developers!

Update April 4, 2016
As of release 6 of the app the dropdown for content type header back to the app. Read more in this blog post.

I received a lot of questions about missing drop-down with predefined encoding values. I feel I owe you an explanation.

Lets begin of what it was. Encoding for payload is nothing more than value for Content-Type header. So when you selected one of predefined encodings (or rather mime types) the app added Content-Type header to the headers list before submission.

Earlier, the drop down list contained a list of predefined values for the Content-Type header. In fact this was only a shortcut for adding a header to the headers list. We all love shortcuts but..

Let's test the prototype!

As you may know lately I have worked on new version of the Advanced Rest Client application. It will change... well, pretty all!

Minor changes will cover:

• storage - change from deprecated WebSQL to IndexedDb
• projects to become "requests groups" - old projects are to much complex and unnecessary. In nev version you will have an option to group requests and easily switch between endpoints
• responses history - it is a new feature, the app will store responses so you can check how your server's response change over time. It also implicate that the app will be useful offline as well.
• better Google Drive integration - it will use different API to connect to +Google Drive. Thanks to a new Identity API in +Google Chrome you will authorize the app in more user friendly way
• upgrade to Chrome App! - instead of opening the app in new tab it will open as native-like application. You may even add the application to the task bar or desktop
• new way hows the requests are made - using new Google Chrome Sockets API the app is able to make a request without a limitations of XmlHttpRequest. You'll be able to set every type of HTTP header. Also I'm planning a raw socket testing implementation.
• change the +GWT framework to +AngularJS - it is more flexible for HTML5 apps than GWT. And it takes much less time to add new functionality or change existing ones
• completely new UI

How about new version?

Hi all,

What do you say for new version of Rest Client for Google Chrome? :)

This is a snapshot of dev version of the app:

It will be faster than current version and it will be totally redesigned. I've added some new features that should help you with your work.

The new version is witted in pure javascript this time. I left GWT behind because for HTML5 features it was a pain in an ass. Now I'm using Bootstrap framework. Mostly for pretty nice styles, out of the box.

I hope you'll enjoy new UI and new set of functionality. I think I've done a lot of good job regarding UX.

It's still under development and there is a lot of work to do. RC version should be available in the end of September. I'm hoping that final version will be ready in middle October.

Give me a feedback what you think about this proposition. I know that it is only one screenshot and only small part of the app but you can see a direction of changes.

P.S.
I'm not planning to maintain server side of the application anymore.  It means that the only way to save and share your data is either save it to file (locally) or save and share it on Google Drive.
If you have any data on application's server you should restore it on your app and save it on Google Drive.

Happy RESTing!

New feature - CodeMirror support for HTTP headers and payload editor

Hi,

Lately I made some changes to the Rest Client.
One of it is a CodeMirror integration for input panels. Now you can edit HTTP headers or payload using convenient editor.

Note: It is a experimental feature and not enabled by default. It still may cause some problems.

To enable this feature go to Settings page and select checkbox near "CodeMirror headers editor" and "CodeMirror payload editor".

The HTTP headers editor

It will highlight your input. Thanks to autocomplete feature it will display suggestions of common HTTP headers with common values. Hit CTRL + space to run autocomplete. It will also work while you typing.

The payload editor

This feature will load CodeMirror editor in the Payload raw input instead of the standard textarea. The editor reconfigures itself according to your Content-type selection, selecting the most appropriate editing engine for your content. 

Currently supported engines are: HTML + CSS + JavaScript (combined or splitted), XML, JSON, SQL.

If you have feature request use Google Code Issue Tracker and submit a request.

Happy RESTing!

It's almost here! New version of Advanced Rest Client

Hi all!

I'd like to inform you that new version of the application is almost ready :)
It took over 3 months but the application was written from scratch. Now it can do a lot more than current version. Thanks for all who submit an issue on http://code.google.com/p/chrome-rest-client/issues/list and helps me improve application.

Note:
There is a number of new permissions required by the application. See bottom of this post for more info.

Let's start from UI.

New version UI

UI now have more modern look. It is not very different from current version, but devil is in the details. Have you noticed that there is new option in menu?

Projects is a new feature. It helps you organize saved requests and you can easily switch between requests sharing it's parameters. More about projects you can find in my previous post.

Project view

OK, let's make a HTTP request:

Still it is not very different form previous version. But as you can see I've added new section to response view. Now Request Headers are also available in application view. And there is more.
Since now you can overwrite browsers headers that are not available for regular XmlHttpRequest! This mean that you can set User-Agent, Accept and many more headers. It becomes possible since new declarativeWebRequest API in Chrome. And here is the bad news. For today it is only available for Chrome Dev Channel (version 23). It will take about 3 months before it becomes available in stable version. Since then I'll send an update to Web Store but it will be available for version 23+.

Let's go on. Lately someone suggest that application should show redirect chain (issiue 67). Well, here it is:

It will show complete request flow. For each redirect it collects information about received headers, status and information is this redirection comes from cache (f.e. HTTP 301) or not.


I've made some improvements to request form panel. You can "open" url input field and create URL using form:

When you need to encode query parameters just pres "enc" button for this parameter. If you need to encode parameter but replace + with %20 just hold CTRL key.


There are changes in settings section as well. First at all "cookies capture" is no more experimental. Well, it is not working very well right now. Results may vary and you can't rely on it. But since application can show all response headers (even those invisible to the XmlHttpRequest object) you can see cookie data in response panel.

There is no JSON headers settings. This is fixed now and list contain all popular json headers definitions.

Important change for the application is import/export options. Since now export to application server is deprecated and this option will be removed December 1st, 2012.

There are better options for import export. First is export to file. Application will generate json file with projects and requests definitions. You can easily change it's content and send file to collaborators. Thanks to this change you don't need to be worry about data sent to application server.

Next step it to implement Google Drive API to save file directly on your drive. Then the application becomes one of the Google Drive applications.

There is a number of new permissions required by application.

• webRequest 
• This is required to observe and analyze traffic - to know when redirect occur and to catch request and response headers 
• declarativeWebRequest 
• This is required to modify request headers by XmlHttpRequest (to remove or add headers)
• background 
• To achieve points above. It is also required to communicate with other extensions.
• storage 
• Chrome provides API for sync data. Application will synchronize some settings like debug and history options.
• history (not changed) is required by URL widget to provide fill support. While typing an URL it search application's and browser's history. When it find matches it will return it in suggestions list. Browser's history is not stored in application. 
• <all_urls> (not changed) is required by application to make any request outside application sandbox. 
• cookies permission has been removed

I hope you like changes and you will like new version of the application. Update will become available in next few weeks. Since then you still can report an issue if you found some :)

Cheers!

Work on new version in progress... :)

If you're wondering when new version of Rest Client will be available I just wanna let you know that it will happen in next one or two months.

Why so long? - you probably ask. Well, it will be totally new version. Whole application is writing right now from scratch. And this needs time :(

Picture below is showing application's start up flow diagram. That shows how many operations is needed to run the application.

What is new in the application? 

First at all: the projects. If you have more than one endpoint of the same webapplication (developer server, test server, production server, etc) then you will can save WebRequests under one project. When you open project you will be able to quickly switch between endpoints and define which part of URL need to change (either protocol, host, path or params) and to what it should change.

For example you have REST project under http://dev.rest.com/api?key=mydevkey&restOfParams

Then you might want to switch to production server but it's host address is http://myproject.com and there you have different API key. 

By creating a project you can define reference URL address http://dev.rest.com/api?key=mydevkey&restOfParams (you can give it a name, like "dev"). Then, for another endpoint, you'll tell the app that it must change server value and key param when switching between endpoints (to defined values).

Second big change in application is closer integration with chrome extensions API.

Now, you can't set some of headers (like cookie, user, user-agent etc). It's not permitted by XMLHttpRequest spec. Using Chrome API application can change headers just before sending request to server, omitting specification restrictions.

Proposed change is integration with Google Drive. Instead of sending saved requests to application's server (app engine) you'll be able to save it to Google Drive and share it with co-workers. It's safer way for you and cheaper for me ;)

Next change is integration with external extensions. Some of you emailed to me to give them possibility to access to the application via extensions communication system (to run application, to replace results window, etc). I'm working on this and it should be available in next version. 

That's all for now.

I'd like to hear feedback from you! If you have suggestions write to me, please.