- 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
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 UTC