On 27 July 2010 03:42, Gregg Wonderly <[email protected]> wrote: > Steve Jones wrote: >> >> >> On 19 July 2010 21:13, Alexander Johannesen >> <[email protected] >> <mailto:alexander.johannesen%40gmail.com>> wrote: >> > Hi, >> > >> > Meh. I find it very silly to blame "cool" REST for the state of >> "trad" WS-*. >> > >> > Steve mentions "If you had to do an integration between 20 different >> > programmes and over 300 systems in a heavily regulated area then you'd >> > use REST?" Yes, why not, since a lot of people are actually doing so? >> >> Where? Seriously give me a few examples where people are integrating >> 300 systems in a heavily regulated industry using REST. >> >> > >> > Maybe the problem is one of context; maybe Steve and the Enterprise >> > world (although I suspect a very specific version of it) are missing >> > out on something? Maybe it's standing a bit still because there's only >> > so far you can go within it? >> >> Yup that'll be it. Its because we don't "get" REST. Or could the >> fact, and it is a fact, that the vast vast majority of integrations >> out there are being done via WS-* indicate that REST hasn't in anyway >> shape or form become as popular in the last 5 years as Web Services >> did in its first 5 years. This to me would indicate that the >> challenge is more a case of the solution not fitting the real actual >> problems. > > From a simple perspective, this is a reflection of the view that REST, as of > yet, is not viewed as anything other than a "transport" technology, in the > form > of HTTP.
Ummm but isn't 5+ years enough for a good idea to gain widespread acceptance? This is where I struggle. The IT industry isn't that dumb and in 5 years REST has basically gone nowhere, certainly when you compare it against 5 years of Java or 5 years of Web Services... hell or arguably even 5 years of Jini. Steve > > Yes there is the WWW, but we are talking about SOA, not just about the WWW. > > From the outside, we see so many other network application protocols use HTTP > (the defacto example of REST) as a transport (and I know it's mostly because > of > port 80 being open through firewalls). So, because there is not a "toolset" > that builds REST applications. > > In the end, I really think that there is a lot of REST going on, but people > just > don't see the bigger picture. As I've said here before, technologies as basic > as RPC are RESTful, because you can consider their "verbs" to just be > "invoke". > The rest of the data that says what remote object and what method and with > what arguments are exactly the same bits and types of information that an HTTP > POST request reflects > > URL == remote object reference - the resource > Request Content == The Method indication and the parameter values > Return Response == Result from method invocation > Hyperlink == A return value that is a remote proxy to another object. > > There are all kinds of things which map into the structure of an HTTP/REST > request/response. > > If you look at, for example, a Jini service registration, lookup and use, you > can see that the ServiceRegistrar returns a ServiceItem which packages all of > the details for using the service. The ServiceItem.service value may or may > not > actually be a remote reference. It might be a smart proxy which wraps one or > more remote references. It might be a smart proxy which looks up the service > to > use dynamically to provide automatic fail over. > > I suppose we could even have the discussion of whether or not any application > protocol running on top of HTTP was inherently restful. If it's not, should > we > venture to say that HTTP is really just a transport since its use doesn't make > something inherently RESTful? > > Gregg Wonderly > >> Steve >> >> > >> > Just a thought. >> > >> > >> > Alex >> > >> > >> > >> > >> > >> > On Mon, Jul 19, 2010 at 7:27 PM, <[email protected] >> <mailto:ashley.mcneile%40metamaxim.com>> wrote: >> >> >> >> >> >> >> >> Hi All >> >> >> >> I am entirely with Steve in this post on the importance of contracts >> >> (Contracts really matter - without them everything becomes tightly bound >> >> no matter what people claim about "dynamism"). >> >> >> >> However, I wonder whether the concept of "contract" that we have >> (based on >> >> stating pre- and post-conditions) is sufficiently general and >> flexible to >> >> handle all the situations we face in defining and building service >> >> software. I have been thinking about this for a while, specifically >> in the >> >> context of extended service collaborations, and written a short paper >> >> (available at >> http://www.metamaxim.com/download/documents/contracts.pdf ). >> >> >> >> I would be interested to know what others on this list think about >> this -- >> >> in particular whether there is any experience of devising or using other >> >> kinds of software behaviour contract. >> >> >> >> Rgds >> >> Ashley >> >> >> >> > >> >> > >> >> > You can read this at: >> >> > >> http://service-architecture.blogspot.com/2010/06/rest-has-put-enterprise-it-back-five.html >> >> > >> >> > Gervas >> >> > >> >> > Reply to sender | Reply to >> >> > group | Reply via web post | >> >> > Start a New Topic >> >> > Messages in this topic (1) >> >> > Recent Activity: >> >> > New Members 4 >> >> > >> >> > Visit Your Group >> >> > MARKETPLACE >> >> > Stay on top of your group activity without leaving the page you're >> on - >> >> > Get the Yahoo! Toolbar now. >> >> >> >> >> > >> > >> > -- >> > Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic >> Maps >> > --- http://shelter.nu/blog/ >> ---------------------------------------------- >> > ------------------ >> http://www.google.com/profiles/alexander.johannesen --- >> > >> > >> > ------------------------------------ >> > >> > Yahoo! Groups Links >> > >> > >> > >> > >> >> > > > > ------------------------------------ > > Yahoo! Groups Links > > > >
