SnapBill API
Web and SaaS
billing api
SHOW HN2011
How HN took it
0 positive, 0 neutral or asking, 1 mixed, 4 critical, out of 5 comments about the project. Thread score -0.46.
Design: 0 for, 3 againstDocs: 0 for, 1 against
The thread, comment by comment
Each row is a top-level comment and its replies, in HN's order. Select a cell to open that comment on HN.
positive neutral or mixed critical about another commenter or something else the maker
What HN said
What people liked
Discoverability via browser is appreciated, but the design needs clearer documentation.
From 1 comment
FWIW, this comment: "The api design functions on the simple idea of having a "GET" request act as a discovery mechanism while "POST" requests perform operations and searches --…
jsarch on HN
Objections
Overloads GET and POST instead of using standard verbs, making it un-RESTful.
From 2 comments
I know that the meaning of REST has been diluted a lot, but this mostly RPC with pretty URLs. I don't understand why they don't support PUT and DELETE. They are already using…
numix on HNI'm more questioning why they thought that was a good idea when there are some drawbacks to overloading GET and some known ways[1] to work around browser limitations of…
hammerdr on HN
Browsing GET returns a form rather than a resource list, which is unexpected.
From 2 comments
I know that the meaning of REST has been diluted a lot, but this mostly RPC with pretty URLs. I don't understand why they don't support PUT and DELETE. They are already using…
numix on HNI'm more questioning why they thought that was a good idea when there are some drawbacks to overloading GET and some known ways[1] to work around browser limitations of…
hammerdr on HN
Doesn't support PUT or DELETE, despite jQuery being available for them.
From 1 comment
I know that the meaning of REST has been diluted a lot, but this mostly RPC with pretty URLs. I don't understand why they don't support PUT and DELETE. They are already using…
numix on HN
Unclear what problem it solves; good documentation would be better.
From 1 comment
What problem is this solving? As a developer I don't want to click around in a web browser to see what I'm able to do at a particular API end point. I want good documentation to…
jessedhillon on HN
Requests
Document that GET is for discovery and POST for operations.
From 1 comment
FWIW, this comment: "The api design functions on the simple idea of having a "GET" request act as a discovery mechanism while "POST" requests perform operations and searches --…
jsarch on HN
Use OPTIONS for discovery instead of overloading verbs.
From 1 comment
Why not just use the OPTIONS verb? You're overloading verbs in order to make your API discoverable. Discoverability is great but there's a supported (and standard) way of…
hammerdr on HN
Questions
What problem does browsability solve compared with good docs?
From 1 comment
What problem is this solving? As a developer I don't want to click around in a web browser to see what I'm able to do at a particular API end point. I want good documentation to…
jessedhillon on HN
Why not use the OPTIONS verb for discoverability?
From 2 comments
Why not just use the OPTIONS verb? You're overloading verbs in order to make your API discoverable. Discoverability is great but there's a supported (and standard) way of…
hammerdr on HNI'd never heard of OPTIONS before. Do you have any links, besides [1], to more resource on it? Is this a common tactic, or is there a more standard way to add "discover-ability"…
kaylarose on HN
Alternatives named
OPTIONS verb for discoverability; HTTP-standard REST design.
From 2 comments
Why not just use the OPTIONS verb? You're overloading verbs in order to make your API discoverable. Discoverability is great but there's a supported (and standard) way of…
hammerdr on HNI'd never heard of OPTIONS before. Do you have any links, besides [1], to more resource on it? Is this a common tactic, or is there a more standard way to add "discover-ability"…
kaylarose on HN