On 13/12/06, Alexander Johannesen <[EMAIL PROTECTED]> wrote: > > > > > > > On 12/12/06, Steve Jones <[EMAIL PROTECTED]> wrote: > > Alex, PLEASE go an read more on WS-*, most people aren't using it as > > RPC _between_ endpoints, but are providing an "object" style interface > > onto the invocation sides of the exchange, thus hiding the complexity > > from the developer. > > Glad you think I know so little of the WS-* stack. :) I use it every > day with a variety of systems, and seriously, RPC is mostly what these > interfaces provide. Sure you can wrap your API's into objects, no > problem, but they still amount to the principles of RPC; call a > function or method on an object with some parameters to invoke > business rules with data. Which is also the same as lobbing a message on a queue. I was talking more about using WS for request/response, DDI or the other perfectly allowable things you can do with WS-*. And of course with WSDL 2.0 you can now do callbacks.
REST is just "in principle" sending a bunch of data to a method (URI/(PUT/GET/etc)) which invokes business rules with data. > And I hope you're not suggesting that OO > hides complexity better than good ol' procedures? :) Most research that I read in the 90s indicated that it did, and certainly the maintenance costs of OO appears to be less than procedural. So yes I would. > > > You also _don't_ have to know "bucketloads" on how that state impacts > > things if the service has been well designed, > > Well, "well designed" is a big cop out, as you can say that about anything. > :) Absolutely, and REST has exactly the same issues in that nothing stops people just sending everything back "on the off chance". > > > you need to know > > _enough_ to complete your interaction. REST also requires you to > > understand the impact of state change. > > Actually, the dynamically REST system we've got only gives you > contextual endpoints, and as such does not require you to know about > state at all in a lot of cases. I need to re-read that REST paper, I'm sure it talks about the client owning the state (hence PUT). > But I guess we can argue back and > forth about this, as we're on a strictly hypothetical level without > proper use cases. Yes, we as developers need to know shit, we need to > know what's going on, and what happens next, WS-* and REST the same. :) > > I find it very hard to talk with you about these things. A lot of > these things are about design more than they are about wheter you > technically can do it. They both can do it, no problem. With REST > there are some principles in place that just simply wins me over, such > as ; Which is why I say the argument is pointless, the key bit (as ever) is in the conceptual architecture and design, REST v WS-* is just a pipes and hammers implementation issue. > > * Guaranteed GET for all resources (with content negotiation if you > want it; > XHTML for browsers [or a Wiki page], > application/x-cool-invoice for your application, XML for debuggers > [browsers set up with it]) which makes it a doddle to see if I'm at > the right place at any given time. I don't need a fancy tool in an IDE > to do this; just a browser, or telnet, which makes it very easy to > capture the info, store it away, proxy it, forward it, document it, > and so forth. Which for someone such as yourself is great, do remember that the majority of IT people out there get the screaming heebie jeebies when they see XML, they NEED the nice IDE. Its a very sad fact about IT but I'm 100% certain that the average technical level of developers is not as high now as it was 10 years ago (probably higher than 5 years ago but that is because in the .com boom people who could spell HTML three times in five were given a job). > > * The resource orientation itself (I don't need to know how to invoke > the "object", only how to use it) which also makes you think in > different semantic terms than objects (more structure and taxonomical > relationships), which is compatible with how most people on the planet > uses URL's. Objects are great for the medium and the small, Services work for the large, I'm still struggling with a simple resource oriented model for a complex supply chain which will work in the way the business operates. > > * URL's are free; they can be bookmarked (by browsers as well as > applications and tools), which helps in exposing your design (both > semantics and schematics) and hook people in (GET is easy; it somewhat > becomes part of your documentation) "somewhat" is a bit optimistic, its like the "code is the documentation" mantra that makes people think commenting is a bad thing. Most people do not want to see XML, so while these things all help you and some limited classes of developers they do not help the majority. The fact is that nice shiny IDEs are what these people need. > > * Optional : Control of API schematics ; dynamically driven > machine-readable API's. (For static lovers: downside is of course that > they're dynamic :) Machine readable APIs.... I've been asking for that but nothing has been forth coming... a pointer would be great. > > * Based on technology that's been around for yonks, and is proven to a > large extent in terms of reliance and scalability, and the technology > specifically is much, much larger than service orientation alone (if > you're into WS-*, you're into service orientation; REST grapples with > much more than that) which means more people have expertize in various > aspects of it. I've been into SOA since before WS-*, SOA has NOTHING to do with the technology implementation in my book. > > I think that's my main positives. And I feel the negatives are more on > people's preference to the dynamic nature of REST more than what you > technically can do with it (but with a bit of proxying and caching, > REST can be pretty static too). Maybe people don't like the > multi-channeled nature of REST (content negotiating, mime-types) or > the lack of strong typing (at least by default; you can push XML > Schema based stuff down your pipeline if you want, but it just ain't > standardized). > > I think a lot of people struggle with the lack of strong typing as > being part of the "API" as such (or, the resource orientation), that > you have to glue a bit instead of having the stack deliver things back > to you in strong typed ways. But is this a technological limitation, > or just a personal preference? TCO, strongly typed languages tend to be cheaper to maintain IME. The main reason for that is that the majority of IT people don't have your ability. > > Alex > -- > "Ultimately, all things are known because you want to believe you know." > - Frank Herbert > __ http://shelter.nu/ __________________________________________________ >
