I'm actually surprised by how positive the responses are for this app.
First, I'm a bit turned off by it's use of the term REST. It's just an HTTP client. Gah, I give up.
I occasionally use postman, but more likely I'm writing a script that I'm going to integrate into my automated testing anyway. Or a simple one-off script with wget. I find that faster to use than a GUI but maybe I'm just getting too settled in my ways.
What was the use case that made you switch to something like this?
Repeated manual testing of APIs at work across different environments. I used to just keep a scratch pad but with paw we were able to set it up and distribute a save file over Dropbox for the team to share. Variables for different environments were a nice touch, I guess you could bash script to your hearts content but this was a little less cumbersome.
Working on a project at work that's got about 50+ endpoints all saved in a single paw file. Paw makes it stupidly simple to go back to any of them. It also remembers headers and POST request bodies which saves a ton of time. Just found out in this thread that you can distribute paw files to the rest of your team to use. Should be onboarding new developers much easier.
Postman let's you do both. Use the GUI for explornig the API and use the CLI (newman[1]) for integrating with automated build systems. The idea is that you should not have to repeat yourself at any point in your workflow.
> REST, in the form coined by Roy Fielding, is actually almost the opposite of what "RESTful" means today,
Not really the opposite. "RESTful", when it doesn't actually refer to Fielding's REST [0], generally doesn't mean anything, its just an empty buzzword being dropped into a product description that communicates no meaningful information at all. Even then, its seems to be intended to communicate "conforming to the REST architectural style", it just fails to do so because its done without any knowledge of the REST architectural style (and not even with an consistent wrong view such that the use of the term could be said to have a particular definition different from that that Fielding laid out for REST.)
[0] Though, to be fair, it often does, although sometimes to only some particular part of it (and not always the same part) as opposed to systems that lack the part being focused on. This use is somewhat consistent with Fielding's, though it would probably be better to focus on naming the particular element.
>Not really the opposite. "RESTful", when it doesn't actually refer to Fielding's REST [0], generally doesn't mean anything, its just an empty buzzword being dropped into a product description that communicates no meaningful information at all.
Well, it instantly communicates: 1) over HTTP(S), 2) using HTTP queries (and verbs) 3) taking advantage of HTTP authentication, caching etc, 4) returning, more often that not, JSON.
I don't think any "majority" even cares about REST let alone know it exists. I also don't see jargon as something that may or may not "catch on", I see it as a way to organize ideas in a professional area so as to ease precise communication. If my peers keep changing the meaning of jargon then it makes it harder for everyone to have meaningful and constructive discussion about our field.
This all can be avoided if people make it as a rule not to reuse names for a new concept Y that is already being used for concept X. What do you see as the reason to reuse names? Do you think we're running out of them?
>I don't think any "majority" even cares about REST let alone know it exists.
Obviously, as its a technical term, "majority" here refers to the majority of the respective technical audience, not the majority across all people.
>I also don't see jargon as something that may or may not "catch on", I see it as a way to organize ideas in a professional area so as to ease precise communication.
The best way to "ease precise communication" though is to use a term as it turned out to be used/understood by most people -- not to insist of its initial intended meaning (which in IT could be off by several decades to its modern use).
>This all can be avoided if people make it as a rule not to reuse names for a new concept Y that is already being used for concept X. What do you see as the reason to reuse names? Do you think we're running out of them?
The thing is, REST initially was some random thing some guy wrote. A person totally irrelevant in the grand scheme of things, not some standards body.
REST became a thing and got relevant only after it was adopted by a critical mass, and in the process people used it in different ways, adopted what they liked, etc. Those changes due to impact with real and different uses, reflect into what people call "REST" today.
Once we called "computers" actual humans doing computations [1]. Then it was some huge machines in corporations. Now we can even call our phones that. It would silly to insist that we should keep computers to its meaning at any fixed point in time.
> The best way to "ease precise communication" though is to use a term as it turned out to be used/understood by most people -- not to insist of its initial intended meaning (which in IT could be off by several decades to its modern use).
How do we know we're up-to-date with the latest definition? And what if someone disagrees with what is the latest definition? How do we even know what "most" people think is the latest definition? Do you see how your suggestion is unrealistic?
But, your next argument is the strongest here, and I stand corrected. I like your computer example. So I'd say if we deprecate the thing that the word meant before (human computers, or REST as defined by one guy and never used) then it's OK to reuse it. I don't know the REST story and have no reason to doubt your version of it, so thanks for the argument!
To be very accurate, REST isn't necessarily based on HTTP. But we like to see "REST" or "RESTful" as the type of HTTP APIs we almost all build nowadays as opposed to other protocols built on top of HTTP like SOAP. (Frankly, who builds non-HTTP REST stuff?!)
First, I'm a bit turned off by it's use of the term REST. It's just an HTTP client. Gah, I give up.
I occasionally use postman, but more likely I'm writing a script that I'm going to integrate into my automated testing anyway. Or a simple one-off script with wget. I find that faster to use than a GUI but maybe I'm just getting too settled in my ways.
What was the use case that made you switch to something like this?