PyCharm 2017.3 EAP 2

After a strong start, we continue our early access program (EAP) with its second release. Download EAP 2 now!

Testing RESTful Applications

Many of us work on web applications which expose a RESTful API, or at least an API that pretends to be RESTful. To test these some of us use cURL, some browser extension, or some other piece of software. There is a REST client in PyCharm, but we’ve decided it can use some improvement, so we’re making an all new one.

The new REST client is entirely editor based, you write your request in a file, and then run the request to get a response. Sounds easy enough, right?

To see how it works, we’ll take the sample application from Flask-Restplus, which as you might expect exposes a todo API.

We’ll start out by creating a new todo. This is done by POST-ing to the /todos/ endpoint. To use the new PyCharm REST client, we should start by creating a .http file. If we don’t intend to save this, we can create a scratch file. Press Ctrl+Alt+Shift+Insert (Shift+Command+N on macOS) to start creating a scratch file and choose ‘HTTP request’ as the type. Let’s type our request into the file:

 

Now click the green play button next to the first line, and you should see that the task was created:

Create a Task with the REST client

You can see the response in the Run tool window, and you might also notice that PyCharm wrote a new line in our file with the name of a .json file. This file contains the response, so if we Ctrl+Click (Cmd+Click) the filename, or use Ctrl+B (Cmd+B) to go to definition we see the full response in a separate file.

Those files become really useful when we do the same request a couple times but get different results. If we use a GET request to get our todo, and then use a PUT to change it, and redo our GET, we’ll now have two files there. We can then use the blue icon with the arrows to see the difference between the responses:

See the difference between REST responses

Now it’s your turn! Get the EAP and try it yourself

Further Improvements

  • Code completion for CSS now supports more notations for colors (rgb, hsl), added completion for CSS transitions, and more
  • React and TypeScript code intelligence: TypeScript 2.4 mapped types, and more
  • Docker improvements: you can now pass –build-arg arguments to a Docker run configuration

To read about all improvements in this version, see the release notes

As always, we really appreciate your feedback! Please let us know on YouTrack about any issues you experience or suggestions for improvement. You can also reach us on Twitter, or by leaving a comment below.

This entry was posted in Early Access Preview and tagged . Bookmark the permalink.

9 Responses to PyCharm 2017.3 EAP 2

  1. Alon Diamant says:

    How about a Swagger/OpenAPI REST client? With support for Bearer authorization header (JWT)? Now THAT would be useful.

  2. Jenkins says:

    How about format curl to this new file format ? )

  3. qft says:

    It would be really nice if there is a way of importing cookies. Manually entering lots of cookies is sure tedious.

  4. Eric PASCUAL says:

    Hello,

    To be honest, I’m not fully convinced by the new tool. And to be fully honest, neither was I by the current graphical one 😉

    After having played a lot with various options such as browser extensions, Postman, PyCharm REST tool,… and of course curl, my final choice is :
    – httpie (and http-prompt for making intensive sessions easier and more efficient) for the interactive testing and API exploration
    – pytest unitests with requests and mocks (even outside the unit testing context) for more convoluted scenarios involving several requests in chain for instance

    I’m far more productive with such a combo, which helps a lot for keeping track of experiments and building collections of easily repeatable tests.

    I confess that I’m more a CLI guy than a GUI addict, even if PyCharm is one of my major workhorses, I use a lot tools such as Vi, Make, (and even LaTeX :))… and my OS is Linux. This for sure introduces a bias in my comment about the the current REST test tool and options such as Postman, Swagger and friends.

    Best regards

    • Dmitry Filippov says:

      Hey Eric,

      thanks for such a comprehensive feedback.
      I think here we might have 2 different things:
      1. GUI vs CLI as a religion or personal preference – we all different. That’s ok. I also prefer some CLI tools to GUI.
      2. The main goal of GUI tools is to make your life easier, save your time from typing and digging into an ever-growing set of CLI tools and options, and more importantly, make it all visual, so you can quickly grasp the information, skim over it and easily dig into. But some of the GUI tools are just not good enough – win on the visual side, but lose a lot on features + usability.

      So here 2 questions:
      1. Is it only the REST client tool that you don’t feel comfortable with or you do all other stuff in the command line (Debugger, VCS, test runner)?
      2. Do you think we could improve our REST client so it covers all your needs in terms of functionality and usability?

  5. Eric PASCUAL says:

    Hi Dmitry,

    Thanks for your quick feedback.

    > GUI vs CLI as a religion or personal preference

    You’re 100% right, and my intent was not to drop yet another troll on the topic :) However in my case, I’d say that’s it’s a matter of preference, not a religion (I use GUI tools for other tasks, the best proof being that PyCharm is opened all day long on my machines 😉

    WRT to your questions:

    Q1: don’t worry, I’m happy with the other IDE graphic tools (at least the ones I use the most, i.e. test runner, debugger, version control). The REST tool didn’t convinced me because of the number of actions required to issue a request (compared with the way I can work with http-prompt for instance, which is IMHO a very good wrapping of httpie, with plenty of good ideas obviously coming from a day to day usage by its creator).

    Q2: I’m afraid it would become complicated and tedious to use if too much loaded with options. My experience in SW development (the first time I put my hand on a keyboard was back in 1976 😉 ) makes me feel that GUI tools are fine for the initial learning phase, or for a simplified usage in the context of the most common scenarios. But as soon as you crowd them with more and more functions and options scattered over dozens of windows, dialog and menus, they start to degrade your productivity (cf MSWord et al. for instance). The other risk is increasing the risk of actions being moved from here to there or implemented differently as new versions are released, which tends to ruin your working habits (cf MSWord et al. again).

    I mentioned LaTeX in the list of tools I’m used to work with (and not only to produce scientific papers or alike) for this precise reason : the stability of my working habits. In addition of its intrinsic strengths when it comes to produce clean and professional documents (i.e. without stuff like “Error xxx not defined” or styles changing without any reason between the start of the document and its end) – but this is another debate 😉 – , it warrants me at 99.99% that what I’ve learned 10 years ago is still valid today and will probably still be valid in 10 years from now. Even if its learning curve is not the easiest you can find, it worth the investment since it will not been lost. This is the same for almost all CLI tools. They are longer to master, but once done, they make you more productive. At least under Unix style OSes.

    So to come back to your question WRT the REST tool, I’d suggest : don’t change it, appart maybe adding a way to show the equivalent curl or httpie command line. This is what http-prompt does, and IMHO this is a great idea since it helps you gearing up by teaching how to use the CLI way of solving the problem.

    My $0.02 😉

    Best regards

    Eric

  6. Denis says:

    Some thoughts about HTTP testing.

    We should have a way to check response against some expectations, just to name this process “testing”. Maybe you can think about embedding some interpreted code block (js/py) and supply it with some response object. Code can check it, and report some result with some way.

  7. Paul Hanchett says:

    Is there any documentation for how this tool can interact? Is it more than a toy? I’m interested in how to do chains of fairly complex automated (and visual!) rest interactions (think OSLC interfaces.)

    • Ernst Haagsman says:

      Currently, the REST client is pretty much what you see here in the blog post. We’re currently working on adding support for scripting and variables, stay tuned for the EAPs of PyCharm 2018.1

Leave a Reply

Your email address will not be published. Required fields are marked *