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

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

Grahame

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