[
Lists Home |
Date Index |
Thread Index
]
On Monday 11 February 2002 03:47 pm, Mike Champion wrote:
> But let's not get into another mutual misconception mismatch thread
> -- Paul's argument seems to be that the REST architecture is at a
> very minimum something to seriously consider when designing the web
> services infrastructure;
Which is a fair argument. REST, as an architectural style, is actually
fairly old (someone else noted this). One of the good things in Roy's
thesis the methodology of defining architectures, and the vocabulary
used to describe them. Giving REST a name is a good thing.
> HTTP to some significant extent implements
> the REST architecture, and sticking (when possible) to those parts
> that overlap with REST seems like a Best Practice guideline; and
> he's predicting that the web services practices that violate REST
> principles and/or HTTP best practices are going to cause their
> perpetrators a lot of grief down the road.
Right. The point here though is that REST was defined as an
architecture... as a set of design constraints used to solve a
particular problem in a particular domain. If there is a mismatch in
the problem domain, it will bring into question the applicability of a
given architecture.
So the *real* question isn't whether we should use REST principals, or
HTTP, or BEEP, or <whatever>. It's "what is the problem being solved"
first and foremost. On other words, while REST is applicable to
distributed hypermedia (but even then, there are issues with URI's as
commonly used), it is an open question whether it is well-suited for
business transactions etc. I personally think there are probably a
*large* number of problems that can be solved well using REST, but
there are a set of problems that aren't really well suited to it
(except in the most abstract sense).
The question below problem domain, and architecture, is of course,
implementation strategy. This is where we ask whether HTTP or BEEP,
or SMTP or <whatever> is applicable. My feeling is that there are
cases where HTTP is useful for REST (like distributed hypermedia), but
I also think a better protocol is possible.
Not that I like web services mind you...
|
