Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Paw – macOS HTTP client for testing and describing APIs

paw.cloud

Post reply on HN
Print view View original

101–110 of 121 posts

Re: Paw – macOS HTTP client for testing and describing APIs

#101

Post by mrcarrot »

mosselman wrote: post #90
fredsted wrote: post #82

Earlier quoted context omitted.

Insomnia doesn't even come close to Paw due to the amount of features Paw has that Insomnia doesn't. Also, Projects are just Paw files. Inside the files you can group and subgroup requests, too. Unless you meant something else?

That might be true. For me Paw's UI doesn't help me (a simple user vs a power user) to work pleasantly. I am forced in Paw to deal with Projects, difficulty to rename requests, etc.

As a self-confessed Paw fanboy, I'm kinda baffled by this. It seems a bit like complaining that you're forced to work with spreadsheets in Excel or text documents in Word. You need _somewhere_ to put the requests, and even if you don't want to have one Paw project per, err... project, you can just create one and then use it for everything and it'll even re-open it automatically every time you open the app.

And, if it helps, you can rename a request in Paw by clicking on its name in the sidebar while you have the request selected or clicking on the name where it shows up as a title in the Description panel in the middle of the screen.

Re: Paw – macOS HTTP client for testing and describing APIs

#103

Post by dep_b »

michaelsbradley wrote: post #93
dep_b wrote: post #72

Earlier quoted context omitted.

Ahhhh that's why I was getting those completely useless Swagger objects! > the usefulness of the export will depend on the extent to which the Paw-user "dressed up" the request objects

OpenAPI / Swagger is just JSON which describes the input and output data from an API's endpoints. If you want to know, prior to runtime (of your code), what kind of data an API will accept and return, and if you don't have access to the API's source code, in what would format would you prefer to have the information documented? I don't have in mind a right or wrong answer, just curious.

Well everything was defined as String even when it was expecting an Int or Bool value. But sometimes an Int still needed to be wrapped in double quotes to work. No date formats. Objects returned of type class A sometimes had only 30% of it's fields populated (like after an insert only the database ID and creation date). Fields expecting an enum like value but the expected values not specified.

I mean it makes sense if you just export some kind of Postman / Paw configuration without paying any attention to it. File > Export > Bye Bye.

Of course most of my complaints are related to a lazy programmer sending "documentation" with the absolute least amount of effort possible, but I now at least understand how it was made and why it was as awful as it was.

Re: Paw – macOS HTTP client for testing and describing APIs

#104

Post by isarat »

I have been a Paw user for 3-4 years now it's super fast and the team delivers new changes without leaving behind the existing user base.

Insomnia is good and better option than Postman and a free alternative. The OSS looks promising as well. It doesn't really matter if it's packed as a web app but electron based apps have decent quality across platforms.

Re: Paw – macOS HTTP client for testing and describing APIs

#105

Post by _pdp_ »

Dim0N wrote: post #99
_pdp_ wrote: post #97

Earlier quoted context omitted.

We will capture this feedback so that we can get back to it. It is very helpful. Thanks. In terms of the verb and the version, you can either select them from the dropdown, type or use dynamic values. The URL and all other input fields, certainly support dynamic values, which can be selected from the dropdown or autocompleted by typing the value text. We have wider support for transforms which can be nested like Paw…

>The tool works in the browser by leveraging a minimal browser extension. Am I dumb or it doesn't seem to work with Safari on Mac, which is the whole point of this thread?

You are not :) We just suck at explaining our tech very well and it takes a while to realise the value here because even I have not seen any other product offering packaged in the way we do it today - so it could be confusing initially. This is why I am starting threads like this.

The browser extension depends on the browser technology as the extension ecosystem is different for each vendor. Currently, we support Chrome and Firefox but due to Web Extensions API adoption, we will be supporting out of the box all 3 major browsers: Chrome, Firefox and IE Edge (no Safari I am afraid).

That being said, the packaged app will provide a standalone version as well which means that there is an easy transition between desktop and web users and all major platforms will be supported.

This is the plan at least.

Re: Paw – macOS HTTP client for testing and describing APIs

#106

Post by tonetheman »

kiliankoe wrote: post #59
OJFord wrote: post #39

Earlier quoted context omitted.

Just to play devil's advocate: I do all of that in Postman, which for the last year or so has also been a native app - at least, in the sense of being non-Chrome, it's not using macOS UI elements. I think different environments is a recent feature too. It's free, and cross-platform. And the team sharing capabilities are cheaper than Paw's. It's odd that Paw seems to bill its single platform nature as a feature. There…

Isn't Postman's "native" app electron-based instead of being the chrome packaged app from before? So they basically went from Chrome to Chromium and started calling it native...

And really they did that because Google decided to take packaged apps away from mainstream operating systems.

Packaged applications still work in ChromeOS but soon packaged apps are going away from Windows/OSX.

Re: Paw – macOS HTTP client for testing and describing APIs

#107

Post by jsjohnst »

_pdp_ wrote: post #105
Dim0N wrote: post #99

Earlier quoted context omitted.

>The tool works in the browser by leveraging a minimal browser extension. Am I dumb or it doesn't seem to work with Safari on Mac, which is the whole point of this thread?

You are not :) We just suck at explaining our tech very well and it takes a while to realise the value here because even I have not seen any other product offering packaged in the way we do it today - so it could be confusing initially. This is why I am starting threads like this. The browser extension depends on the browser technology as the extension ecosystem is different for each vendor. Currently, we support Chr…

> This is why I am starting threads like this.

Genuine question, but why not fix your own website to tell your product’s story rather than pepper the web with small pockets of useful info about your product leaving visitors to the real deal confused?

Re: Paw – macOS HTTP client for testing and describing APIs

#108

Post by jsjohnst »

azr79 wrote: post #98
mosselman wrote: post #22

I have a Paw license and recently I started using Insomnia instead: https://insomnia.rest/ I find Paw's project management very annoying. It assumes that I am working on some project and wants me to organise everything like that. Fine, lets do it, so where are my projects? They are hidden in some dropdown that you can have fun finding. Insomnia is much cleaner and more to the point.

this is clearly an ad for insomnia, in no way this shitty web app is better than PAW, which a native app, fully integrated with macOS and with features you didn't even know you needed, so please cut the bullshit with some weak excuses about some inexistent project management issues.

You might want to review the rules of HN.

Re: Paw – macOS HTTP client for testing and describing APIs

#109

Post by michaelsbradley »

dep_b wrote: post #103
michaelsbradley wrote: post #93

Earlier quoted context omitted.

OpenAPI / Swagger is just JSON which describes the input and output data from an API's endpoints. If you want to know, prior to runtime (of your code), what kind of data an API will accept and return, and if you don't have access to the API's source code, in what would format would you prefer to have the information documented? I don't have in mind a right or wrong answer, just curious.

Well everything was defined as String even when it was expecting an Int or Bool value. But sometimes an Int still needed to be wrapped in double quotes to work. No date formats. Objects returned of type class A sometimes had only 30% of it's fields populated (like after an insert only the database ID and creation date). Fields expecting an enum like value but the expected values not specified. I mean it makes sense i…

Indeed, it sounds like there was a bit of a problem "between keyboard and chair" when it came to the Postman / Paw user with whom you interacted.

I had good success, just recently, using Paw to knock out the broad strokes an OpenAPI description, including indications of integer, string, boolean, date, etc. After I got the hang of thinking in terms of OpenAPI, I converted the JSON to YAML and started fine-tuning and DRY'ing the description in Emacs.

I would still use Paw as an exploratory tool — it's not perfect, but I find it more convenient than maintaining a collection of scripts and snippets to experiment with API input/output. Next time I need to write an OpenAPI description, though, if I can't auto-generate it from the server code (that was the case recently), I'll just author it by hand. It's not too big of a chore when done in YAML format, with the help of "feedback loops" per ReDoc[1] and Swagger Editor[2].

[1] https://github.com/Rebilly/ReDoc/

[2] http://editor.swagger.io/

Re: Paw – macOS HTTP client for testing and describing APIs

#110

Post by _pdp_ »

jsjohnst wrote: post #107
_pdp_ wrote: post #105

Earlier quoted context omitted.

You are not :) We just suck at explaining our tech very well and it takes a while to realise the value here because even I have not seen any other product offering packaged in the way we do it today - so it could be confusing initially. This is why I am starting threads like this. The browser extension depends on the browser technology as the extension ecosystem is different for each vendor. Currently, we support Chr…

> This is why I am starting threads like this. Genuine question, but why not fix your own website to tell your product’s story rather than pepper the web with small pockets of useful info about your product leaving visitors to the real deal confused?

This is a good question. Of course, we are working on it and we are also building a very complex product at the same time. So while the main site is nowhere near what we want it to be it does not mean that we cannot publicly share what we are currently doing. And yes it would have been a lot more useful if I had shown you an amazing landing page but unfortunately it is not ready yet.

I hope that some of you may see a potential and although may disagree with the styles and color schemes keep faith in us and come back to check it out later when we have landed the themes, the desktop version and the new extension.

It is still useful application and all discussed changes are in the pipeline.

Post reply on HN