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

From: Samuel Erdtman <[email-masked]>
Date: Fri, 20 Jul 2012 13:01:54 +0200

After following the general dissuasion the last couple of days I have
a few questions/thought.

How is statelessness affected by introducing session headers and more
persistent connections for multiplexing and server push?

Have the requirements for REST APIs been considered? I have not seen
any one mentioning this aspect of http2, but it should be since if
current trends continue API calls will generate more traffic then
direct end-user browsing in the future.

Much effort is put in to solving bandwidth and number of connections
problems, should we also consider how resources could be
specified/marked as offline available. I don´t think this is problems
of the future though since bandwidth, battery and connectivity gets
better all the time.

It has been a flood of emails the last couple of days so I have not
ben able to read all in detail, i.e. I might have missed if there has
been discussions on these questions/thought previously, in that case
I´m sorry for bringing them up again.

Regards
//Samuel

---

From: Andy Wenk <[email-masked]>
Date: Fri, 20 Jul 2012 13:22:25 +0200

Hi Samuel,

> direct end-user browsing in the future.

could you point out what you mean here? I don't get the direct context
to the HTTP/2 protocol

> I´m sorry for bringing them up again.

Cheers

Andy

-- 
Andy Wenk
Hamburg - Germany

---

From: "Eric J. Bowman" <[email-masked]>
Date: Tue, 24 Jul 2012 17:26:58 -0600

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 25 Jul 2012 11:41:11 +0200

On 2012-07-25 01:26, Eric J. Bowman wrote:
> ...

Do you have REST-related concerns beyond the ones related to 
intermediaries (which I share)?

Best regards, Julian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Jul 2012 08:23:19 -0400

Since REST is a particular style constraint on Web Service protocol
design, the requirements of REST should logically be a subset of the
requirements for unconstrained Web Service protocol design.

On Wed, Jul 25, 2012 at 5:41 AM, Julian Reschke <[email-masked]> wrote:
> Do you have REST-related concerns beyond the ones related to intermediaries
> (which I share)?
>
> Best regards, Julian
>

-- 
Website: http://hallambaker.com/

---

From: "Eric J. Bowman" <[email-masked]>
Date: Wed, 25 Jul 2012 13:05:09 -0600

> intermediaries (which I share)?

The intermediary issue is merely an example of my primary concern,
which is a failure to use REST as an evaluation tool here.  Resulting
in long, repetitive threads about ideas which should be considered non-
starters, as they represent a break from the established architecture.

The problems lie with HTTP, not REST, as per Chapter 6 of Roy's thesis,
which could be used to establish some goals for moving HTTP forward.
Such a process may even lead to a new constraint, say privacy, which
would create a superset of REST.

Seems to me, that would be a better procedure than "winging it"
architecturally (starting with solutions to specific problems, rather
than establishing overall goals) and hoping for the best.

-Eric