W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: [ietf-http-wg] <none>

From: Eric J. Bowman <eric@bisonsystems.net>
Date: Tue, 24 Jul 2012 17:26:58 -0600
To: Samuel Erdtman <samuel@erdtman.se>
Cc: ietf-http-wg@w3.org
Message-Id: <20120724172658.f1e7af36.eric@bisonsystems.net>
Samuel Erdtman wrote:
> 
> Have the requirements for REST APIs been considered?
>

Doesn't look like they have.  My impression, after catching up on 100's
of posts, is that plenty of folks are ready to throw out the baby (REST)
with the bathwater (HTTP 1).

Leading me to give +1 to PHK's point, echoed by others, that starting
with proposals before establishing goals seems to be skipping some
steps, i.e. moving too fast.

Intermediaries aren't optional to the REST style, they're integral to
the success of the Web.  HTTP 2 should not, IMO, result in a new and
incompatible architectural style which only scales well for those big
companies with a global DC presence and CDNs.

I prefer my guerilla approach, which REST allows to compete with the
big boys in terms of user-perceived performance, without spending a
small fortune on hosting/CDN service.  Or equipment, by requiring fancy
new processors to keep on top of the traffic, where my cheap desktop
router +Squid isn't hampered by a 20-year-old ARM design for its CPU.

Please don't relegate me to HTTP 1.1 forever, by pulling the REST rug
out from under me with an HTTP 2 which represents its own, untested,
unproven, and undefined (it'll be whatever we come up with to solve,
piecemeal, a bullet-point list of problems) architectural style which
turns out to be incompatible with my system architecture, requiring a
complex redesign instead of a simple protocol upgrade.

Can we instead use REST to guide the development of HTTP 2?  Seems to
me that's its purpose, evaluating protocol design...

-Eric
Received on Tuesday, 24 July 2012 23:27:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 24 July 2012 23:28:02 GMT