jheising/hapi

A spec for Humanized web APIs, aka HAPI. The goal of HAPI is to define a standard for creating Web-based APIs that are machine ready but human friendly— a self-documenting API.

hapi's Issues

Requiring parameters to be passed through the GET query string limits length unpredictably

Passing all your parameters for the object through the query string is a very dangerous idea; the Request-URI cannot safely be over about 2,000 characters and breakage will be unpredictable. This means that you cannot, for example, safely transmit an image of even one kilobyte (remember too that it'll be percent-encoded which inflates by a maximum factor of 3). The specification is thus only useful for tiny data.

Seriously, doing everything over GET with its empty entity body simply does not work. There is a reason for the other methods like POST. (Don't get me wrong—I laud your attempts to make APIs more accessible and I recognise the problems you've identified, but there are reasons why REST ends up as complex as it is, just like there are reasons HTTP has ended up as complex as it is—did you know HTTP/0.9 had only the GET method and no notion of headers? (A complete request was GET /foo␍␊ and a complete response foo!))

"delete" links automatically followed

The part of the specification:

A HAPI must support the HTTP GET verb on all operations.
[…]
CREATE: https://api. [domain] / create / [resource_type] / with / ? [parameters]
UPDATE: https://api. [domain] / change / [resource_type] / called / [resource_id] / to / ? [parameters]
DELETE: https://api. [domain] / delete / [resource_type] / called / [resource_id]

is at odds with RFC 2616 §9.1.1. Consider user agents with link prefetching or Web crawlers and the resulting unintended destruction of data. How do you intend to resolve this conflict?

npm publish

Hi!

I can't find humanized-api from npmjs.com.

Could you consider doing npm publish to the package?