W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: Should Web Services be served by a different HTTP n+1?

From: Grahame Grieve <grahame@healthintersections.com.au>
Date: Thu, 24 Jan 2013 03:18:50 +0000
Message-ID: <CAG47hGa+Hp4LmepYOsCXM9p-L-XrP3a6o1S3RorEYiJK8SEmFA@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
Cc: Phillip Hallam-Baker <hallam@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Hi Tim

> I disagree strenuously.  The semantics of HTTP as they are today map well
> onto my RESTful-app-construction needs.

well, here's an issue I have. What error code should an http server return if
a proposed update is not suitable because of the content of the submission?
There's nothing wrong at the http layer - it passes authenticaion, currency
and content type checks, and parses, ok. But there's something in the content
that violates server business rules. Something like trying to submit and
order with an identifier that has already been used, for example.

What would be right http status code to use? It's a client error, right?
The nearest appropriate status code would be 422, but I'm not sure
whether that can be used outside webdav. Either way, there's a bunch
of things I would expect in an application exchange protocol that don't
map that well.

I don't think that a different protocol is a good idea, but the discussion of
what's planned for HTTP/2 seems very focused on browsers & the web to
me, and doesn't seem to me to adequately consider the huge use that
exists for application/application communications

Received on Thursday, 24 January 2013 15:11:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:09 UTC