- ... There was discussion of REST-* on this list when it came out and IIRC the criticism was quite well explained in those posts. Check out the postings aroundMessage 1 of 45 , Jul 1, 2010View SourceOn Jun 30, 2010, at 11:40 PM, Bryan Taylor wrote:
>There was discussion of REST-* on this list when it came out and IIRC the criticism was quite well explained in those posts. Check out the postings around the date of the quoted posting by Roy.
> Jan wrote:
>> I found the Rest-* effort at http://www.jboss.org/reststar . The name of this project tweaks me, but some of the specs under it seem relevant.
> Roy on REST-*: http://tech.groups.yahoo.com/group/rest-discuss/message/13266 ('nuf said :-)
> I agree these have nothing to do with REST exactly, and I hate the REST-* name. The individual specs seem to try to create RESTful implementations of integration patterns in the same way as Atom and AtomPub attempt to solve pub/sub in a RESTful way. That said, Roy's statement "this is the single dumbest attempt at one-sided 'standardization' of anti-REST architecture" seems mysterious to me
Basically the problem is that REST-* attempts to bend REST to match the usuall enterprisey mind set, claiming that this and that would be a must-have. What should really happen is that "enterprise people" learn from the Web and adjust their mind set to pruodcue systems that are less complex and more easily evolvable.
It just makes no sense to claim complexity is necessary just because one fails to understand how to make things simpler. REST-* originates from this kind of thinking and hence claims that there are lots of things that need to be addressed.
The truth is that all we need is proper media types and a little more guidance how the Web kind of doing things can be applied in enterprise contexts (e.g. match the open, 'Darwinistic' way to an environment that simply needs a little more planning and budgeting).
> and is quite conclusory. How did he leap from these being about something other than REST to them being "anti-REST". Would AtomPub become anti-REST if it had been wrongly renamed RestPub?which is true because they violate REST's stateless server constraint (among others I guess).
> He makes two assertions that follow:
> - Distributed transactions are an architectural component of non-REST interaction.
> - Message queues are a common integration technique for non-REST architectures.Yes, because they violate the hypermedia contraint (would need to check which else).
> I could also make the statement that pub/sub syndication models are a common integration techniques for non-REST architectures, which would not prove that Atom and AtomPub are non-RESTful.Note that AtomPub is essentially a media type specification that defines the semantics of several hypermedia controls (e.g. the edit-link relation). AtomPub uses straight-forward HTTP for communication between client and server. Actually it would not need to say anything about that but provides the HTTP interaction examples as developer hints.
The HTTP-based use of the formats specified by AtomPub is not PubSub but polling. An AtomPub client polls feeds via GET to check whether the feed has changed.
Also note that PubSub is not forbidden by REST. There is simply no appropriate method in HTTP for doing pubsub but you can allways add one in if PubSub is the right model for you (see ,).
PubSub with HTTP works like this:
The server could then POST to the Reply-To URI.
(But I doubt that it is ever really of practical relevance. I'd go with polling due to the much greater simplicity).
> There are patterns of integration, and I expect to find them in every architectural style.This is an interesting topic because you can start this train of thought one level up: If your problem space requires interation (the Web does, and enterprise IT clearly also does) then it is much wiser to pick an architectural style that is tailored towards dealing with integration. Such a style must constrain the connectors (think component API) to be uniform because only then can you avoid to have to do point to point integration every time two components talk to each other.
REST is such a style (surprise, surprise :-) through and through. REST has been designed to deal with integration problems (complexity and change).
Interestingly, no OO-based pattern (especially not the service pattern) out there attempts to constrain the connectors of components. That is why all these attempts (e.g. SOA) are essentially meaningless when it comes to reducing integration complexity. IOW, they cannot guarrantee reduced complexity and good evolvability - REST does because it limits the variation of the component interface (to be uniform).
> If there is some impossibility conjecture here, I'd like to see it stated in a more analytic way, without the bashing.Maybe - but then... he has said it all before and REST reall is one of those things on earth that are *not* up to interpretation.
Additionally - that is his style and I presonally find it very refreshing. I only lack the competence to adopt it :-)
> It may be that a distributed transaction pattern must must violate one of the RESTful architecure principles, but this is far from obvious.It requires understanding of REST, yes. OTH, most of the problems people have (at least I did) is due to the fact that 'they' lack proper knowledge of software architecture in general (See Perry&Wolf, Garlan&Shaw, Taylor&Medvidovic and the first half of Roy's dissertation). If you started with that knowledge already - understanding REST would be pretty quick as would be understanding the rationale behind the mentioned constraint violation. (Personally the journey took me about 8 years and I keep having epiphanies :-)
> Maybe this is some deep corollary of the CAP theory or something. Or perhaps not.Well, that is a layer 4 issue (transport). What do MQs do in terms of reducing integration complexity or making a system more easily changeable? All the latter is a layer 7 issue.
> The corresponding statement about message queues seems baffling. These solve a harder problem than guaranteed delivery. Queues solve guaranteed delivery to exactly one consumer among competing consumers with some fairness guarantees.
> How would I implement a RESTful way to have airport passengers acquire taxi transportation at the airport in a fair way?
<transport-request from="airport" goods="passenger"/>
Location: /taxi-requests/778 ----------<< Your process instance resource
<transportation> --------------------<< Your process instance data
<status>on its way</status>
Jan Algermissen, Consultant
NORD Software Consulting
- ... In this case, yes, though it is true for any client. ... which it gets from the media type definition, yes. ... A user (or configured robot) willMessage 45 of 45 , Jul 8, 2010View SourceOn Jul 6, 2010, at 1:00 AM, Jan Algermissen wrote:
> Roy,In this case, yes, though it is true for any client.
> On Jul 6, 2010, at 3:03 AM, Roy T. Fielding wrote:
> > Reliable upload of multiple files can be
> > performed using a single zip file, but the assumption being made
> > here is that the client has a shared understanding of what the
> > server is intending to do with those files. That's coupling.
> Trying to test my understanding:
> By 'client' you are refering to 'user agent'?
> My understanding is that the user agent has no shared understanding beyond how to construct the submission resquest upon the activation of a hypermedia control. (Web browsers know how to create a POST request from a user's submission of a form)which it gets from the media type definition, yes.
> The user however does have an understanding (expectation) of what the server is intending to do with those files. This expectation is the basis for choosing to activate the hypermedia control in the first place.A user (or configured robot) will understand their own intent,
yes, but not necessarily how the server intends to accomplish that
functionality. A user is unlikely to know that a given service
needs guaranteed delivery, since best-effort delivery is the norm.
One would have to add that to the interaction requirements, which
means standardizing that kind of interaction through additional
definitions in the media type or link relations and sending
enough information with the request to enable the recipient to
verify the received message integrity, and both sides need to
know that the request needs to be repeated automatically if
the checks fail. And that still doesn't tell us what to put in
the representations being sent. That's why this kind of
There is also no need to limit yourself to one interface.
Look at all the interfaces on Apache ActiveMQ, for example
The so-called REST protocol calls for POST to a given
queue URI, which I'll just assume isn't guaranteed delivery.
Guaranteed delivery could probably be added with a simple
message integrity check if the messages are unique, but I
would prefer a more explicit pattern.
For example, we might define a message sink with a URI such
that each client knows (by definition) that it should append
its own client-id (perhaps set by cookie) and a message counter
to the request URI, as in
PUT URI/client-id/count HTTP/1.1
and then the client can send as many messages as it wants,
provided the count is incremented for each new message, and
the server must verify (and store) the MIC before responding
with a success code. Each message can therefore be logged,
verified, etc., just like a message queue with guarantees.
We could try to standardize something like what I describe above,
but it would require multiple independent implementations and a
lot more free time than it probably deserves. In any case, it also
begs the question of why would we want to do this using HTTP
[aside from just avoiding firewall blocks, which is not a
The fact is that most people write message queues for systems
that are more operational than informational -- i.e., they are
doing something, usually at a high rate of speed, that isn't
intended to be viewed as an information service, except in
the form of an archive or summary of past events. Would a
more RESTful message queue have significant architectural
properties that outweigh the trade-off on performance, or
would it be better to use a tightly coupled eventing protocol
and merely provide the resulting archive and summaries via
normal RESTful interaction? That kind of question needs to
be answered by an architect familiar with all of the design
contraints for the proposed system.