[
Lists Home |
Date Index |
Thread Index
]
On 4/13/05, Rich Salz <rsalz@datapower.com> wrote:
> Sorry if conflating HTTP and HTTP/REST bothered you. I guess I don't
> understand the differences all that well.
>
> I thought I understood, and answered your question.
>
> Q. HTTP is extensible, why can't you build what you need?
> A. Because I need shared state,
'Shared state' seems more like a derived requirement from your
authentication mechanism choice and its implementation.
You stated:
""Yeah, I know, it's not really without state, it's just
that all the state is in the representations sent back
and forth. Not good enough -- you need *shared state*
that doesn't get communicated. Go see the SSL/TLS
or WS-SecureConversation specs.""
You need shared state. Shared state that doesn't
get communicated. Shared state that doesn't
get communicated over HTTP. And you claim that the
'statelessness' of HTTP is a problem.
I must be mis-userstanding something because that
is a real head-scratcher. To narrow the conversation,
I'll go read WS-SecureConversation.
> and because every
> client operation ends up being a POST.
Again, this seems more like a derived requirement
from how the authentication and/or protocol was
implemented, though at this point I have scant
information to go on. Are there more detailed
reasons as to why every client operation
ends up being a POST?
> The first
> seems impossible, and the second means the framework
> benefits are nil.
Even if every operation is a POST, I believe there would be a
benefit from leveraging the extensible authentication mechanism
outlined in RFC 2617. The most obvious one of which is that it can
be applied to resources who representations aren't just
'application/soap+xml', i.e. HTML, images, etc.
Thanks,
-joe
--
Joe Gregorio http://bitworking.org
|
