4 ms·

Maybe I never appreciated the power of Postman but I never understood why they thought it would be a good idea to charge monthly for a tool that's just a gui on

Maybe I never appreciated the power of Postman but I never understood why they thought it would be a good idea to charge monthly for a tool that's just a gui on top of curl (or Invoke-WebRequest for those of a Windows persuasion).

np_tedious 5y ago
I think sharing among teams is supposed to be the draw. I don't really see the point either
- SideburnsOfDoom 5y ago
  If you use a tool whose state is stored in text files, then git solves the "sharing among teams" issue for free. So it's a paid solution to an invented limitation.
- devoutsalsa 5y ago
  My team uses Postman, but we largely stick to just sharing curl requests. No one seems interested enough in the team functionality to figure it out.
  - awill 5y ago
    So your team is the perfect candidate for the paid version, and doesn't see the value. I agree with others that Postman created limitations just to justify a paid version. Those types of services/apps rarely succeed.
    - devoutsalsa 5y ago
      We have the paid version. People just can't seem to bother using the premium features.
tgv 5y ago
Makes two of us. Maybe, if you're working on a really large project? But then there should be time and money to set up a central tool for mockup and testing.
koffiezet 5y ago
Sorry, but with that attitude, why use curl, and not just netcat or socat? Or just write bash scripts manipulating sockets directly? I think you underestimate a bit what postman can do. Just a few things: import openapi specs and do pretty complex requests with a few mouse-clicks, supports various auth mechanisms (oauth/jwt/...), allows for some scripting, run mock versions of an API spec, generate request code for various languages and frameworks, and yes, copy a request you created with point&click as a cli curl command. On top of that, you can easily save and share this in teams.
- the_gipsy 5y ago
  You're proving the point, nobody would pay a monthly subscription to use curl over netcat.
  - deleted 5y ago
    [deleted]
  - sxg 5y ago
    Are you sure? Or do people just not have the opportunity to pay for curl?
    - kajaktum 5y ago
      Its not obvious that CURL would be as popular as it is if it started with a pay to use model. Maybe it never got the attention it has and never got popular?
    - the_gipsy 5y ago
      Yes, people would just script netstat. I mean the argument is getting ridiculous, as another sibling points out, cURL would be nowhere today if it wasn't FOSS.
    - matt_heimer 5y ago
      If you want the opportunity you can go to https://curl.se/donation.html https://curl.se/donation.html
obowersa 5y ago
To preface this, I'm not a massive fan of postman. I find the user experience to be counter intuitive compared to the likes of insomnia. With that said we use it pretty heavily so I might be able to provide some insights. This is kind of expanding on koeffiezets comment. For me postman's 'value add' can be broken down into three areas. Technical Capability: - UI alternative to curl This is the most basic usage and a lot of the of other functionality is extensions of this. For simple get/post requests, this is definitely the case. I wouldn't trivialise it though. For folk not familiar with curl there's a lot of gotchas when it comes to escaping, handling auth, etc. I'd say that the UI on top of curl is more accurately viewed as an alternative to things like jetbrains's build in http client. - The ability to import openapi/swagger/protobuf (as of recently) and generate collections This will be the most commonly pointed at benefit of postman (and others like it) in my opinion. It's a pretty solid one, especially if you integrate with the API during your build process to version/upload the API specs. This combined the the 'UI alternative to curl' really gives a lot of the foundational power for the other postman features. Even as openapi/swagger docs on steroids with a richer http client this gets pretty powerful. Especially with the sharing capabilities which I'll touch on under the team side of things. As with a lot of this stuff, you /can/ do this without postman. You could use the openapi client generator to produce a curl command. - Auth handling So postman has pretty rich support for a few auth types (api key, no auth, oauth 1.0 & 2.0, signatures, ntlm etc). This I think is where some of the power of postman really begins to shine (and tools like it). Handling auth in curl can be a real pain. Creating a way of handling auth which can be shared across a team becomes even more of a pain, especially if we're talking about auto refresh and the like. At this point you're really in the realm of writing small-medium custom scripts to wrap the auth handling, save the tokens, refresh. Having a standardized way of handling this with the ability to extend it if needed can become a massive time-saver. - Mock Servers There's a bunch of ways to do mock servers and I wouldn't say postman is technically the best ( personal preference is stuff like wiremock). With that said, sometimes 'technically the best' looses out to what's immediately available. Having it built into the system which already has your open api specs, has SWE familiarity and is already there will often make this win out. It can also get folk thinking a bit more about their mocks/contracts than they would be otherwise because it's just part of the existing toolchain. You could technically do this with netcat, or using a language specific approach, or another tool like wiremock. The first is going to be a pain to maintain, the second doesn't work great for multi-language environments and while wiremock and it's ilk are easy to get up and running with, they do require additional setup and management. - Postman echo Kind of an alternative to the like of pipewire or running your own nc/other implementation. Simple concept, simple implementation, but having the ability to create an endpoint to post/etc data to, see what the output looks like and run it in a place which other engineers can access and you can collaborate easily on the output is a nice to have. Basically saving on the setup time/individual contributor trying to collaborate side of things. - Newman This loops back to curl. A CLI tool for running postman collections. I'm giving it a special callout because if it wasn't for newman I'd have a lot more reservations about using postman. With newman, being able to take collections/imports from the UI and then use them with newman to do things like helm chart tests/continuous testing/run easily in a container allows the effort invested into creating stuff in postman and extend it beyond just the local dev experience. - Other There's also a whole bit around the API workflow/editor that I'm not going to touch on as I dont know that side of it well enough, but, it is there and something to be aware off. 'Team' Capability: With everything above, it's important to remember all of this can be done in a shared collaborative environment with a full audit trail and potentially SSO depending on the tier. Removing all the friction from that is a pretty big deal (especially as companies grow). The point about using a text based standard is valid (one of the things I like with jetbrains http client is this). But managing that for all the functionality of postman would be a challenge and bits would be likely to rot. Just having a tool which does most of it well enough can be enough as it reduces friction. Another point on this is cross os teams. We have a mix of linux/windows/osx users. Curl is great, and does work reasonably well on windows, but trying to maintain scripts/bespoke implementations/knowledge across folk on all these platform is a losing battle. Integrations: Kind of a final and often overlooked note, but there's also a rich integration system with postman. Stuff like integration with new relic/data dog/etc to record test results gives one example but it's a pretty solid ecosystem. Closing thoughts ? That was a ramble. To summarise: - Postman is definitely bloated, but that bloat/bredth of functionality can be useful - You can do everything postman does without postman, but depending on the team size/number of services/etc there's value in having a standardized, cross-os and easy to share solution. If I was just doing stuff as an individual contributor or had a single team ? I wouldn't necessarily go with it. For larger orgs or as you go from startup-scale up there are definitely advantages in having a master of none tool to help adoption. Regardless of if it's postman, insomnia or hopscotch I think reducing it to curl with a UI is leaving a lot on the table.
petard 5y ago
Maybe it is the same good idea as Slack is just a GUI on top of IRC
criddell 5y ago
It's a good idea because there are a lot of companies out there who want to pay a monthly fee.

np_tedious 5y ago

I think sharing among teams is supposed to be the draw. I don't really see the point either

SideburnsOfDoom 5y ago
If you use a tool whose state is stored in text files, then git solves the "sharing among teams" issue for free. So it's a paid solution to an invented limitation.
devoutsalsa 5y ago
My team uses Postman, but we largely stick to just sharing curl requests. No one seems interested enough in the team functionality to figure it out.
- awill 5y ago
  So your team is the perfect candidate for the paid version, and doesn't see the value. I agree with others that Postman created limitations just to justify a paid version. Those types of services/apps rarely succeed.
  - devoutsalsa 5y ago
    We have the paid version. People just can't seem to bother using the premium features.

tgv 5y ago

Makes two of us. Maybe, if you're working on a really large project? But then there should be time and money to set up a central tool for mockup and testing.

koffiezet 5y ago

Sorry, but with that attitude, why use curl, and not just netcat or socat? Or just write bash scripts manipulating sockets directly? I think you underestimate a bit what postman can do. Just a few things: import openapi specs and do pretty complex requests with a few mouse-clicks, supports various auth mechanisms (oauth/jwt/...), allows for some scripting, run mock versions of an API spec, generate request code for various languages and frameworks, and yes, copy a request you created with point&click as a cli curl command. On top of that, you can easily save and share this in teams.

the_gipsy 5y ago
You're proving the point, nobody would pay a monthly subscription to use curl over netcat.
- deleted 5y ago
  [deleted]
- sxg 5y ago
  Are you sure? Or do people just not have the opportunity to pay for curl?
  - kajaktum 5y ago
    Its not obvious that CURL would be as popular as it is if it started with a pay to use model. Maybe it never got the attention it has and never got popular?
  - the_gipsy 5y ago
    Yes, people would just script netstat. I mean the argument is getting ridiculous, as another sibling points out, cURL would be nowhere today if it wasn't FOSS.
  - matt_heimer 5y ago
    If you want the opportunity you can go to https://curl.se/donation.html https://curl.se/donation.html

obowersa 5y ago

To preface this, I'm not a massive fan of postman. I find the user experience to be counter intuitive compared to the likes of insomnia. With that said we use it pretty heavily so I might be able to provide some insights. This is kind of expanding on koeffiezets comment. For me postman's 'value add' can be broken down into three areas. Technical Capability: - UI alternative to curl This is the most basic usage and a lot of the of other functionality is extensions of this. For simple get/post requests, this is definitely the case. I wouldn't trivialise it though. For folk not familiar with curl there's a lot of gotchas when it comes to escaping, handling auth, etc. I'd say that the UI on top of curl is more accurately viewed as an alternative to things like jetbrains's build in http client. - The ability to import openapi/swagger/protobuf (as of recently) and generate collections This will be the most commonly pointed at benefit of postman (and others like it) in my opinion. It's a pretty solid one, especially if you integrate with the API during your build process to version/upload the API specs. This combined the the 'UI alternative to curl' really gives a lot of the foundational power for the other postman features. Even as openapi/swagger docs on steroids with a richer http client this gets pretty powerful. Especially with the sharing capabilities which I'll touch on under the team side of things. As with a lot of this stuff, you /can/ do this without postman. You could use the openapi client generator to produce a curl command. - Auth handling So postman has pretty rich support for a few auth types (api key, no auth, oauth 1.0 & 2.0, signatures, ntlm etc). This I think is where some of the power of postman really begins to shine (and tools like it). Handling auth in curl can be a real pain. Creating a way of handling auth which can be shared across a team becomes even more of a pain, especially if we're talking about auto refresh and the like. At this point you're really in the realm of writing small-medium custom scripts to wrap the auth handling, save the tokens, refresh. Having a standardized way of handling this with the ability to extend it if needed can become a massive time-saver. - Mock Servers There's a bunch of ways to do mock servers and I wouldn't say postman is technically the best ( personal preference is stuff like wiremock). With that said, sometimes 'technically the best' looses out to what's immediately available. Having it built into the system which already has your open api specs, has SWE familiarity and is already there will often make this win out. It can also get folk thinking a bit more about their mocks/contracts than they would be otherwise because it's just part of the existing toolchain. You could technically do this with netcat, or using a language specific approach, or another tool like wiremock. The first is going to be a pain to maintain, the second doesn't work great for multi-language environments and while wiremock and it's ilk are easy to get up and running with, they do require additional setup and management. - Postman echo Kind of an alternative to the like of pipewire or running your own nc/other implementation. Simple concept, simple implementation, but having the ability to create an endpoint to post/etc data to, see what the output looks like and run it in a place which other engineers can access and you can collaborate easily on the output is a nice to have. Basically saving on the setup time/individual contributor trying to collaborate side of things. - Newman This loops back to curl. A CLI tool for running postman collections. I'm giving it a special callout because if it wasn't for newman I'd have a lot more reservations about using postman. With newman, being able to take collections/imports from the UI and then use them with newman to do things like helm chart tests/continuous testing/run easily in a container allows the effort invested into creating stuff in postman and extend it beyond just the local dev experience. - Other There's also a whole bit around the API workflow/editor that I'm not going to touch on as I dont know that side of it well enough, but, it is there and something to be aware off. 'Team' Capability: With everything above, it's important to remember all of this can be done in a shared collaborative environment with a full audit trail and potentially SSO depending on the tier. Removing all the friction from that is a pretty big deal (especially as companies grow). The point about using a text based standard is valid (one of the things I like with jetbrains http client is this). But managing that for all the functionality of postman would be a challenge and bits would be likely to rot. Just having a tool which does most of it well enough can be enough as it reduces friction. Another point on this is cross os teams. We have a mix of linux/windows/osx users. Curl is great, and does work reasonably well on windows, but trying to maintain scripts/bespoke implementations/knowledge across folk on all these platform is a losing battle. Integrations: Kind of a final and often overlooked note, but there's also a rich integration system with postman. Stuff like integration with new relic/data dog/etc to record test results gives one example but it's a pretty solid ecosystem. Closing thoughts ? That was a ramble. To summarise: - Postman is definitely bloated, but that bloat/bredth of functionality can be useful - You can do everything postman does without postman, but depending on the team size/number of services/etc there's value in having a standardized, cross-os and easy to share solution. If I was just doing stuff as an individual contributor or had a single team ? I wouldn't necessarily go with it. For larger orgs or as you go from startup-scale up there are definitely advantages in having a master of none tool to help adoption. Regardless of if it's postman, insomnia or hopscotch I think reducing it to curl with a UI is leaving a lot on the table.

petard 5y ago

Maybe it is the same good idea as Slack is just a GUI on top of IRC

criddell 5y ago

It's a good idea because there are a lot of companies out there who want to pay a monthly fee.