3 ms·
I've seen this used by people who are not quite devs but work with devs, as in not-really-technical PMs. They're happy to not have to deal with git, but they st
by vladvasiliu 5y ago
I've seen this used by people who are not quite devs but work with devs, as in not-really-technical PMs. They're happy to not have to deal with git, but they still need to see that some API replies with the expected result. They absolutely love postman.
- pletnes 5y agoSure thing, but why not keep the source in git, then distribute to end users, as we do with other software artifacts?
- vladvasiliu 5y agoI may be mistaken since I'm not directly a part of this, but the way I understand this works is the other way around: it's the PMs who more or less come up with the API specs / explore upstream APIs, and it's also them who will do the querying. So they're the "first" as well as the "main" users of those collections. So basically, as they expect to be able to write their own requests and save / share them, they would have to either directly interact with git (which they'd rather avoid - at all) either have the "real devs" provide some kind of functionality similar to postman but backed by git. Needless to say, we're not in the business of developing a postman competitor, so devs have other things to do.