Ability to save multiple requests

[mrpoundsign]

Ability to save multiple requests

[ahmadnassri]

Agreed.

I'm struggling which feature to build first: Request History vs Saved Requests, since they are both very similar (coding wise) ...

[mrpoundsign]

I personally feel that saving is a better option. I may be testing and changing my requests as I develop, and when I am done I want to save but I may not care about every request I make (as many may be essentially wrong).

Also as I am developing interfaces to other services, I need to manually form REST requests until I have the time to develop the feature and use the other REST client to do operational work, loading the saved requests and modifying the values for the specific task I need to handle without re-entering the same information. History seems a bit more complex.

Is there a way to reuse the URL field to store the REST parameters perhaps?

[nadavoid]

I would vote for adding Saved Requests first. The main way I would see this differing from history is that some things may need placeholders instead of real data. History would contain real data. Placeholders could be used as part of a URL or the value of a parameter, or a portion of the RAW body.

The way I would see Request History working would be like this: every time I submit a request, the details of that request (and response?) are stored in a history. In the process of development and testing, I'll accumulate a history of hundreds of requests. I would see the oldest ones rolling off, keeping in history a maximum limit of a configurable number.

But I could see "starring" or "favoriting" certain requests in my history, to keep them from rolling off.

To @mrpoundsign 's comment: Maybe a combination of a saved request with placeholder, then loading overrides to set values in those placeholders would do what you want?

Thank you Ahmad! I'm enjoying using this app already!

[ahmadnassri]

@nadavoid I think you nailed it on the head in terms of the differences between the two ... I think that's the way I will move forward with this.

@mrpoundsign the URL thing is an interesting one, and I have thought about it, but Chrome doesn't show the URLs apps (or at least mine doesn't, does it show on yours?)

but that got me thinking, I can do a an omnibox (the URL field in chrome) integration where you can initiate a REST call from any tab you're on, the syntax would probably look something like the curl syntax ...

also, on that thought (ideas are rolling in now) I can do a right click integration for links on pages where you can initiate a REST call to that link!

thoughts?

[nadavoid]

Love the idea of omnibox integration. (never knew that was called an "omnibox") That would provide a smooth transition in my existing workflow, which does start with simple GET requests, and I currently do just start by entering a URL in the browser.

I don't see any immediate need for right-click integration on links, but could be handy when looking at WADL documentation. I'd see that as a separate feature request.

[mrpoundsign]

I wonder if it could be done from the development console "network" list so
you can grab an existing request and turn it into a rest client window.

On Wed, Oct 12, 2011 at 10:23 AM, David Lanier <
[email protected]>wrote:

Love the idea of omnibox integration. (never knew that was called an
"omnibox") That would provide a smooth transition in my existing workflow,
which does start with simple GET requests, and I currently do just start by
entering a URL in the browser.

I don't see any immediate need for right-click integration on links, but
could be handy when looking at WADL documentation. I'd see that as a
separate feature request.

Reply to this email directly or view it on GitHub:
https://github.com/codeinchaos/rest-console/issues/50#issuecomment-2381917

Brian Nelson

[ahmadnassri]

@mrpoundsign funny you said that, Google just recently announced the ability to make extensions within the Development Console, so one can extend the functionality ... its still under the experimental APIs and I've been playing with it, its pretty cool, but unfortunately it has to be a separate app/extension ... but that is not a big deal.

so yes, once that feature goes out of experiments, I'll be adding it ;)

however, that doesn't justify leaving the "history" feature to the Development Console, since a lot of people don't even know how that it exists, never-mind knowing how to use it.

[bobmoff]

+1 for Saved Requests.

[danolsen]

Is the feature going to be added? This feature would be very useful.

[ahmadnassri]

yes, its in the works :)

[c089]

Along with this feature, might I suggest that in addition to "saving" (i.e. to a file), you could have an export (maybe serialize to a JSON string) so a request could be easily shared with others?

[hoffmanc]

What's the status of this feature?

[bwestergard]

I too am interested in this. If no one has started, I might take a crack at it.

[ahmadnassri]

this is already in the works on the development branch and near ready.

perhaps I'll spend some time this weekend listing all the remaining tasks/steps into issues on github so if anyone is able to pitch in they'd know what to tackle first ...

[martinambrus]

👍 I'm for saving, too - has this progressed in any way since April? Also, would it be able to save the RAW body at all? At the moment, it doesn't seem to work that way.