Hello, I let go of the other mail, even though I think we disagree strongly about a lot of things. However, you brought up some stuff in this one that I feel people have let slip, and, since decency and smart thinking is beneath me, I'll rise to the task ;
Steve Jones <[email protected]> wrote: > I think the other one is that a resource oriented style doesn't really > scale to enterprise processes very well, conceptually a service paradigm > is better at that level (which can be implemented as resource oriented > in software if required) which means you do have a contextual shift > which many people find hard. I find it hard to believe you've gotten away with this. :) "Enterprises processes doesn't scale using resource orientation as a concept, but you can of course implement it using resource orientation in software"? No, there's no contextual shift between a service end-point being a SOAP stream nor a HTTP stream. You can perfectly well do enterprise processes in REST just like any other technology / interface you want. Here I find you're creating a straw-man out of perhaps bad implementations you've seen. >> But the beauty of REST is that a >> "service interface" (i.e., a resource) can support multiple media >> types, making interface versioning much simpler. You can add support >> for new media types whenever you like without breaking existing >> clients. > > But I'm not sure that this is actually the real problem. "Media Types" > require > local specification as to what they are xml/invoice, xml/cod, xml/etc which > then in turn requires the actual type of that schema to be defined. I don't follow the logic of this one. How is WS-* and contracts any different to this critique? As to local specification, that applies to anything in the whole world ever developed through space and time (unless we venture into more semantic technologies?), and this is why in REST the reuse of the generic interface is often pushed as a good thing. Do OPTIONS on a resource to see if some of your definitions fits theirs, match if they do, or do something generic if they don't ; that's a pretty foundational way not to break systems, reuse the interface for all, extend it for those who can extend it. WS-* does it through a pre-agreed contract, REST does it on the fly (but can of course do upfront as well if you really want it). Again I feel that this comes down to the fullness of the WS-* stack as an implementation vs. the abstractness of REST as an architectural style, a rather unfair comparison. Sure, that might be a straw-man of my own making, but it seems that any time the answer from us RESTafarians comes back requiring a bit of hacking it is this very hacking you're opposed to? That either it works out of the box, or it is the wrong answer? > You can make the effort with REST to define the formal process for > your local area but that isn't liable to be accepted more broadly which > will give longer term issues. Hmm. I don't see the standards process being magically better just because we put REST in it, of course. But that process is hardly a problem with REST itself, and the focus are shifting to grand-scale implementers? Like I said earlier, if the big guys actually wanted to standardise such REST processes it would be a welcomed effort for sure, but the truth is that those guys don't want nor need it given the amount of money and resources that's been poured into the other. Maybe that cuts to the core of this whole thing, though; as long as WS-* which has been so heavily resourced does the job, why REST? I think there's a good reason REST is used by smaller players. > I'm not convinced that the REST benefits are actually scalability > and flexibility, sure people say the words but where is the evidence > that REST will make stuff scale better or be more flexible? This can't be a serious observation, no? Load-balancing and distribution at the interface level is far easier than at the back-end level (especially where we're talking about channels or streams; the trick is to break the stream into smaller streams and distribute them accordingly). Or are you talking about something else? (How long did it take to get dynamic end-points into WDSL?) > Now I'd like to see some of this as well, for instance in the federated > MDM space and as an exchange mechanism, however I'd like them > to do it based around a standardised approach to exchange and > contractual definition rather than each having their own proprietary > REST approach and media types which would make integrating > multiple solutions a right pain. Uh, yeah, why don't they all just agree on a set of media-types and use a generic REST interface? WOuld work just as well. I don't know, every time you say "REST" you seem to be saying "can't be standardized." Hmm. Just like with strict contracts and static end-points, you *can* do that in REST even if it isn't best practice ... Regards, Alex -- Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps --- http://shelter.nu/blog/ ---------------------------------------------- ------------------ http://www.google.com/profiles/alexander.johannesen ---
