Show HN: I made a simple persistent counting API (opens in new tab)

I believe most anayltics platforms use/support GET, e.g. google analytics, mixpanel etc. If you limit yourself to use only POST, you will limit users from using your tool in areas like email pixel tracking where only GET is allowed.

Yeah, see I'm kind of torn, because GET just makes it so dang simple. POST requests, though semantically correct, add a small amount of overhead to implementing the counter. I'm not really concerned with spiders, as the URLs are intended to be obscure + robots.txt. In addition, future versions could include simple basic auth for private URLs. Though I intend to keep public URLs around for fun and drive by counting.

Yes ... And to address one of the comments above, PATCH is used to merge data into an existing record while PUT is used to replace the existing contents. This is a bit of an odd case since you wouldn't be sending data in either case.

Web crawlers and web page views index using GET; if GET affects your server state, so do page views and indexing.

GET is idempotent. That's not outdated, and it's not arbitrary: it is literally stated in the protocol specification. It's a useful distinction created and used by professionals to maintain sanity in complex schemes of communication.

Please do not ignore technical details because you think you're smarter than everyone else on the planet, or that the problems they solved a decade ago somehow went away in the face of node.js.

edit: Just in case you (or anyone reading this) is unaware of it,

http://www.ietf.org/rfc/rfc2616.txt (or pretty: http://pretty-rfc.herokuapp.com/RFC2616)

Find Section '9.1 Safe and Idempotent Methods'.

> why should they respect the semantics?

Because they are going to be used in an environment where there are lots of other things built based on the specifications and which are likely to rely on (or, in some cases, have inspired) the semantics described in the HTTP spec -- including lots of the infrastructure of the web.

> Those were arbitrary and out dated.

There may be some issues with them, but those would fall under the umbrella of "clearly-identified compelling reasons".

They were arbitrarily decided a long time ago by people who put much more thought into it than you or I, most likely.

You can just use a 128-bit random string as a group key. That's how "private" photos are implemented on most photo sites, for example.

> Unless they know what counter you're using or you make it public, it's unreasonable that anyone could mess with your counter.

...or you choose convenient, meaningful $group and $id names, which makes even unintentional collisions not at all unlikely.

This would be an example of security through obscurity.

It's probably not that they're hard, but rather that they might require some boilerplate code and bloat that somebody might want to offload to an external service like this one.

The idea was to make something easier than booting up a database. Personally, I just needed a semi-persistent count that I could discard later. This fit the bill for me, and being able to retrieve the counts via JSON, I can easily add them to my Geckoboard dashboard.

It's a node.js app that has until recently been a single-process app. I just integrated clustering to take advantage of the extra cores Linode gave me. It's a simple but high traffic service and node has handled it like a champ. I have a relatively inexpensive account with Linode that so far has suited the site's traffic just fine.

I'm exploring the idea of offering a higher-tier service. The general feature list is outlined on getjsonip.com but pricing isn't finalized. I'm still collecting signups and feedback right now.