eljefe7000 / RestApiToText

RestApiToText Notepad++ plugin that uses input from an editor tab to make a REST call and display the results in a new tab.
GNU General Public License v3.0
27 stars 4 forks source link

Version 1.2 of the plugin does not catch whole response content #2

Closed dinkumoil closed 3 years ago

dinkumoil commented 3 years ago

Description

Since v1.2 of the plugin, only a small part of the response's content is pasted into a new editor tab.

Steps to Reproduce

  1. Open Notepad++ and paste the following content to a new document:
get https://api.github.com/repos/notepad-plus-plus/notepad-plus-plus/commits
**headers**
accept: application/json
  1. Press keyboard shortcut associated with the plugin's Make REST call menu entry.

Expected Result

A rather long list of recent commits to the Notepad++ repository on GitHub should be displayed.

Actual Result

The list of commits is garbled, it ends somewhere in the middle of the first commit's data set.

Applies to

Notepad++ v7.9.3 RestApiToText v1.2

Additional Information

The above issue was not present in v1.1 of the plugin.

eljefe7000 commented 3 years ago

@dinkumoil, thanks for catching this. Not sure what's happening at this point, but I will troubleshoot and get back to you.

eljefe7000 commented 3 years ago

@dinkumoil , I have a fix for this issue and am working on a version 1.3 that you will be able to download and use immediately. I'll keep you updated.

eljefe7000 commented 3 years ago

@dinkumoil , I have deployed a fix, which is version 1.2.1 rather than v1.3. You can find the 32-bit DLL here and the 64-bit DLL here

In case you haven't done it before, here are the steps to overwrite the DLL once you've extracted it:

  1. Open Notepad++ and go to Plugins->Open Plugins Folder...
  2. Close Notepad++.
  3. In the Explorer window you created from Step 1, open the RestApiToText subfolder.
  4. Overwrite the RestApiToText DLL with the one you downloaded.
  5. Reopen Notepad++.

Thanks for pointing out the issue.

dinkumoil commented 3 years ago

Tested and works. Thanks a lot for this quick fix!

Since the above is not an official release, I keep this issue open. You can close it according to your liking.

eljefe7000 commented 3 years ago

@dinkumoil , you are most welcome! I will keep this open until it is released as part of the nppPluginList project. Also, if you can think of any improvements, please let me know and I will try to implement them when I can.

dinkumoil commented 3 years ago

@eljefe7000

if you can think of any improvements

When thinking about it, escaping of URL parameters came into my mind, would be really useful. Actually, I have a use case for that at my current project at work.

dinkumoil commented 3 years ago

@eljefe7000

And also optionally showing response headers could be useful.

dinkumoil commented 3 years ago

@eljefe7000

Another possible improvement:

It seems like the plugin refuses to transmit a request body when sending a DELETE request. AFAIK the standards do not explicitely forbid DELETE request bodies, though it is very common to ommit them. So, please allow your plugin to send DELETE request bodies.

eljefe7000 commented 3 years ago

@dinkumoil , thanks for your suggestions! I have been kicking around the idea of displaying response headers, either by themselves or just before the response. I might add a new section with a name like RestToTextApiOptions to allow users to customize the response for things like this. Also, do you happen to have an example of escaping URL parameters, just so I'm on the same page as you? I will try to implement all of these suggestions, and will keep you updated.

dinkumoil commented 3 years ago

I have been kicking around the idea of displaying response headers

Nice to hear that!

do you happen to have an example of escaping URL parameters

In my job im currently dealing with a REST API. One of its calls needs a GUID as parameter, passed as part of the URL. The GUID has to be provided including curly braces. These have to be escaped to get a valid URL. That means

GUID={B48447DA-DC4B-45DB-9910-AD7EDD4E923B}

has to be turned into

GUID=%7BB48447DA-DC4B-45DB-9910-AD7EDD4E923B%7D

The standard Notepad++ plugin MIME Tools calls this transformation URL Encode. This might also be the official/well known name for that functionality.

Thank you for your efforts writing and maintaining this plugin. It came exactly at the right time. Only a few weeks after its first release I had to start working with this REST API I mentioned above. I know, there is Postman for dealing with REST APIs but I prefer to use small and lean tools as long as my requirements ar so low that tools like Postman would be pure overkill.

eljefe7000 commented 3 years ago

@dinkumoil , thanks again for your input! I have the same opinion with regards to Postman. It's a great tool, but it is overkill when you want a quick way to validate or inspect a REST call. If you encounter any other needs when working with your REST API, just let me know and I will be happy to try and incorporate them if possible.

And thanks for the GUID use case. While debugging the URL-encoding, I realized that I was sending the query string unencoded, but I noticed that my REST API was able to read the GUID anyway. Please see below.

In RestApiToText, before calling my local REST API: image

In my REST API: image

What happens when your REST API tries to process the GUID?

eljefe7000 commented 3 years ago

@dinkumoil , almost forgot. There is a new version of the plugin is now available here for 32-bit and here for 64-bit. There is still the bug I mentioned in my previous post where the URL is being sent unencoded (had a false positive there and released before I found it. I'm working to fix it now)

dinkumoil commented 3 years ago

@eljefe7000 Thank you for the new version, works like a charm!

Currently I don't have any further wishes which functionality could be added to the plugin. But I did not test all HTTP commands, only GET, DELETE and POST

Thanks again for this useful plugin!

eljefe7000 commented 3 years ago

@dinkumoil , glad I could be of service! Full disclosure, the URL-encoding piece is not released yet, even though I thought it was. I am encoding the query string, but then I'm not replacing the original query string before I send the request. My testing produced a false positive, so I need to fix my test. Fortunately, it looks as though you're able to process your GUID parameter anyway, which is good. I will create a bug and resolve the issue.