Google GData (and the associated calendar, spreadsheet, blogging, notebook etc.) APIs are very RESTful (and built on top of Atom and APP, the Atom Publishing Protocol); I don't know whether they fall under your B2B definition. I expect more and more Atom/APP-inspired and Atom/APP-based APIs to follow.
Stefan -- Stefan Tilkov, http://www.innoq.com/blog/st/ On Jun 1, 2007, at 8:36 PM, ash galal wrote: > > This is a great comment. > My question: Does REST fits in all kinds of interactions, > specifically B2B interaction? > If the answer is "Yes" then please point us to an example of such > implementations. > What I found out that most of REST implementation is just POX/HTTP > and violate the REST principles. (Amzon is an example) > If the answer is "No" then such articles about REST might imply to > the reader that REST fits all kind of interactions. Which, in my > opinion, it does not fit B2B. > Thank you > Ash Galal > Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > Let me reiterate. REST is about the way you design/implement a > capability (i.e., a service). If you abide by the REST constraints, > your service will exhibit a number of desirable characteristics, such > as simplicity, scalability, performance, reliability, evolvability, > maintainability, visibility, and portability. If you expose your > RESTful resources using pervasive protocols, such as HTTP, then they > are also extremely accessible. > > Note that all of these desirable characteristics support > non-functional requirements. Business people don't necessarily care > about non-functional requirements, but they still provide value to the > business. > > I also want to point out the REST does not preclude the use of SOAP. > You lose some of the power of the deployed HTTP infrastructure is you > use SOAP headers rather than HTTP headers to convey infrastructure > information, but nonetheless, SOAP over HTTP can be RESTful. (The > debate between REST and WS-* is like comparing apples and oranges.) > > Anne > > On 6/1/07, Steve Jones wrote: > > Out of interest what is the view around Security, Reliability and > the > > other important "enterprise" qualities that don't current exist > in the > > REST world? > > > > I completely agree that vendors will be starting to have "REST" > > tooling in their IDEs (this year I'd say) , mainly because it isn't > > hard and adds yet another "tick" into the boxes and keeps certain > > sections of the developer community happy. My question though is to > > what are the actual BUSINESS benefits of doing REST v WS (i.e. in > > having two tracks) and I've yet to see a single article looking at > > whether REST (or WS) actually progress us towards business goals. > > > > Its really not suprising that the vendors want to do this as what is > > the difficulty for them? None whatsoever, and indeed its gives them > > the opportunity to resell the old stuff with a slightly different > > interface. How does this progress us towards the business goals? Not > > at all as it is just a revision at the current level of > operation, in > > fact its BELOW that current level as it doesn't include the > security, > > reliability and addressing elements that WS-* has already addressed. > > > > In my simple world we are still arguing about the moving parts of IT > > and not really progressing the business agenda. > > > > On 01/06/07, Anne Thomas Manes wrote: > > > You know, it's interesting. Pete Lacey, the most vocal pro-REST > > > advocate on my team thought that my presentation was much too > > > conservative, and I made it sound like REST was much too > challenging > > > for most organizations to tackle at this point. (True > assessment.) He > > > wants me to advise our clients to immediately desist from using > WS-* > > > except when requirements specifically call for it. (Not gonna > happen > > > anytime soon.) But what was reported in the press and has been > bandied > > > about in the blogosphere is that I predicted that REST would > trounce > > > WS-*. (False assessment.) > > > > > > What I did predict is that major vendors would start to deliver > within > > > the next 2-3 years frameworks in their tools and platforms that > > > assisted developers in creating RESTful services, and at that > point > > > REST would become more palatable for the "early adopter" > enterprise > > > developer. It will take about 5 years for REST to cross the > chasm and > > > be adopted by the "early majority". But that doesn't mean that I'm > > > predicting the imminent demise of WS-*. I agree with Todd that > there's > > > room for both noun-oriented systems and verb-oriented systems. > > > > > > I disagree that REST resources can't be "services", though. > From my > > > perspective, SOA encompasses many different types of services, > > > including method-oriented, resource-oriented, event-driven, > > > workflow-driven, and goal-driven services. Just as I rejected the > > > whole concept of "SOA 2.0" being a new combination of SOA and > EDA, I > > > also reject the idea that ROA is somehow incompatible with SOA. > (No > > > doubt now someone is going to start promoting "SOA 3.0" as the > evolved > > > SOA that includes SOA + EDA + ROA. Please NO! The original > concepts of > > > SOA have always encompassed all types of services.) > > > > > > REST can be service oriented. A RESTful resource still exposes an > > > interface, but the interface is uniform. REST adds constraints > to SOA, > > > and in the process imparts a number of desirable properties to the > > > services that conform to the constraints. REST is an architectural > > > style for implementing services. SOA is at a much higher level > -- the > > > fact that you're exposing functionality as services in the first > > > place. > > > > > > Today WS-* hits a sweet spot in enterprise application > development, > > > but that's primarily because the vendors provide tools and > frameworks > > > that enable web service development. For REST to "win" in the > > > enterprise, the vendors need to provide comparable frameworks that > > > enable RESTful development. That will probably require some > different > > > modeling tools that help designers model their resources > (rather than > > > their methods). > > > > > > And of course I might be blowing smoke here. Anyone that spends > the > > > time to figure out AOP usually comes away thinking that this is > > > awesome stuff, and they don't understand why it hasn't swept the > > > development world. But it hasn't, and it probably never will. > The same > > > may be true of REST. Anyone that spends the time to really > understand > > > this architectural style usually becomes a convert. But it's > possible > > > that the learning curve is just too steep, and the vendors > won't be > > > able to supply frameworks that effectively guide developers into > > > designing RESTful systems. But it seems clear that they're > going to > > > try. > > > > > > From my perspective non-RESTful POX over HTTP is a poor > substitute for > > > SOAP. If you're not going to do REST, then it's better to stick > with > > > SOAP. > > > > > > In response to Stuart's remark: > > > > > > > > WHY, for example, I may want to have a URI > > > > > for everything interesting instead of just embedding an > arbitrary > > > > > context-specific identifier in my XML document. > > > > > > To be RESTful, the XML document would include the URI of the > resource > > > of interest. By naming the resource and using hypermedia to > reference > > > it, you get the benefits of the Web. (Hypermedia as the engine of > > > state.) It's an incredibly powerful feature. > > > > > > Anne > > > > > > On 5/31/07, Todd Biske wrote: > > > > I certainly agree that SOA needs to be a balance between > producer and > > > > consumer interests. Unless you're a monopoly, or at least an > 800- > > > > pound gorilla, success with a producer-focused view will be > difficult. > > > > > > > > I can also see your point that the REST debate offers > interesting > > > > lessons on being consumer-oriented, however, I think that's > more a > > > > statement on the potential complexity of WS-* than it is > about the > > > > potential benefits of REST. I suspect that the alternate > approach in > > > > those situations are more likely to be POX/HTTP than REST. As > Anne > > > > points out in her Burton Group APS blog, having every single > resource > > > > available as a unique URI is something that people are still > getting > > > > their arms around. While each resource is accessed via a uniform > > > > interface, navigating the interactions across those resources > in code > > > > could get very complicated. This is where it becomes ROA, not > SOA. > > > > If the developers try to stick with an SOA approach, there's > a risk > > > > that it all just gets buried in POST operations which then > begins to > > > > look at lot like how WS-* works, minus WSDL and everything > that goes > > > > into SOAP headers. > > > > > > > > Like many others on the group, I think there are places for > both REST > > > > and WS-*. WS-* certainly has a sweet spot in many of the > enterprise > > > > integration problems, and you can argue that REST has the most > > > > potential on the Web. Because the Web is a bit more > associated with > > > > loose, mashup type approaches that aren't as prominent in the > > > > enterprise, it has a lot more to prove to gain adoption in the > > > > enterprise. That will happen, it's just a matter of how long. It > > > > won't be done at the detriment of WS-*, however, but rather as > > > > complimentary to WS-*. There will be pockets where WS-* is being > > > > used today where REST may be more appropriate, others where REST > > > > enables new solutions that didn't previously exist (probably > in the > > > > presentation space), and then others where WS-* will thrive > and you > > > > won't see any REST. For example, I'm pretty sure that Anne and > > > > others have mentioned management technologies as a potential > fit for > > > > REST, and I agree with her. When you see that one of the WS-* > specs > > > > in the management space is WS-Resource, it would seem to make > sense > > > > that this could be a good fit for REST. :) > > > > > > > > -tb > > > > > > > > > > > > On May 31, 2007, at 11:21 AM, Stuart Charlton wrote: > > > > > > > > > I find if people look at SOA as a producer-focused view, > i.e. "I have > > > > > these capabilities to offer in the granularity that is > convenient for > > > > > me & aligned to my business", then certainly it's very > different from > > > > > REST. > > > > > > > > > > Some alternatively view SOA as a twin-track analysis (a > balance > > > > > between > > > > > producer and consumer interests), which an approach that > some analysts > > > > > like CBDI promote. This approaches values synergy and > serendipity > > > > > across producers & consumers over alignment. There, I think > REST > > > > > offers many interesting lessons on the extent that one can > > > > > "consumer-orient" one's services: the impact of global naming, > > > > > interface generality, etc. > > > > > > > > > > As for the POX/HTTP v. REST confusion, I tend to look at > the tools as > > > > > the culprit. There aren't really good agent-programming > environments > > > > > that concretely highlight WHY, for example, I may want to > have a URI > > > > > for everything interesting instead of just embedding an > arbitrary > > > > > context-specific identifier in my XML document. > > > > > > > > > > Cheers > > > > > Stu > > > > > > > > > > > > > > > --- Todd Biske wrote: > > > > > > > > > >> One point that Anne made which still doesn't get a lot of > press is > > > > >> the difference between Resource Oriented Architecture and > Service > > > > >> Oriented Architecture. In a companion article, it was > called out > > > > >> that REST is about the nouns, where SOA is about the > verbs. This is > > > > >> > > > > >> part that I think needs some honest debate. Is a resource > oriented > > > > >> view of the world going to be better than a service > oriented view? > > > > >> > > > > >> Many people keep associating REST with SOA, but I think > that's an > > > > >> inaccurate portrayal. The people I've spoken with have > been doing > > > > >> POX over HTTP, which is not REST, and I'd argue that there > are some > > > > >> very big differences. > > > > >> > > > > >> -tb > > > > >> > > > > >> On May 30, 2007, at 1:34 PM, ash galal wrote: > > > > >> > > > > >>> This is a very good article, but the problem with REST in > the > > > > >>> machine-to-machine interactions. Till now, I did not see > anything > > > > >>> about such interactions in any REST articles, seminars, > or books. > > > > >>> REST is very good concept for B2C but I couldn't find any > > > > >>> justifications for B2B. > > > > >>> If someone have such justifications or examples about B2B > in REST, > > > > >> > > > > >>> please publish it here. > > > > >>> Thank you > > > > >>> Ashraf Galal > > > > >>> > > > > >>> > > > > >>> > > > > >>> Gervas Douglas wrote: > > > > >>> I have a vague feeling that the subject of REST has > arisen before > > > > >> in > > > > >>> this Group..... > > > > >>> > > > > >>> <> > > >>> architecture (SOA) projects, you probably are > not doing > > > > >>> representational state transfer (REST) now, but within > the next > > > > >> five > > > > >>> years you probably will be. > > > > >>> > > > > >>> That is how Burton Group Inc. analysts answered their own > > > > >> rhetorical > > > > >>> question – REST: Is it the next big thing? – with a > resounding yes > > > > >> at > > > > >>> a Web conference on Tuesday. Repeating the mantra "The > Web is REST. > > > > >>> REST is the Web," Anne Thomas Manes, vice president and > research > > > > >>> director at Burton, said the only thing new about REST is > that it > > > > >> is > > > > >>> starting to catch on with SOA tool vendors and the open > source > > > > >>> community as well as architects and developers. > > > > >>> > > > > >>> "REST is not new because REST is in fact the Web," she > said. "The > > > > >> Web > > > > >>> has been around for 15 years, but very few people have > used it for > > > > >>> service-oriented systems. Mostly REST is being used for > visual > > > > >>> applications, browser-based applications." > > > > >>> > > > > >>> That is about to change. Looking to the future, Manes > listed time > > > > >>> frames Burton predicts for REST adoption now and in the > next three, > > > > >>> five and 10 years. > > > > >>> > > > > >>> "Today, it is only innovators that are really working > with REST," > > > > >> she > > > > >>> said. "In three years, we should see the early adopters > start to > > > > >> play > > > > >>> with REST. It will probably be five years before it is > adopted by > > > > >> the > > > > >>> early majority. We anticipate that the late majority will > probably > > > > >> not > > > > >>> pick up REST for at least another 10 years." > > > > >>> > > > > >>> What will drive REST adoption eventually is that it brings > > > > >> structure > > > > >>> in the form of "constraints" to the sometimes chaotic > world of Web > > > > >>> services, which includes those pesky rogue services, > according to > > > > >>> Burton. This will provide a level of maturity for SOA > development. > > > > >>> > > > > >>> Peter Lacey, senior consultant at Burton, played devil's > advocate > > > > >> on > > > > >>> the Web conference, arguing the current state of Web > services > > > > >>> standards are inadequate and hamper SOA development, > which needs > > > > >> the > > > > >>> constraints REST development will bring. Manes did not > agree that > > > > >> the > > > > >>> state of Web services standards is hopeless, but she did > advocate > > > > >> the > > > > >>> transition to REST for SOA. > > > > >>> > > > > >>> So what does this mean to IT departments in general, and > enterprise > > > > >>> architects and developers in particular? Manes said where > they end > > > > >> up > > > > >>> on the adoption curve depends on the skills of the > architects and > > > > >>> developers and their willingness to think outside the box of > > > > >>> object-oriented programming. > > > > >>> > > > > >>> She explained that the basic concept of REST, which > starts with > > > > >>> sending out GET commands sent via HTTP to URIs to > retrieve data is > > > > >>> simple enough. But she noted that even long-time REST > advocates > > > > >> admit > > > > >>> having trouble thinking of applications in terms of REST. > > > > >>> > > > > >>> Borrowing a verb from Robert A. Heinlein's fictional Martian > > > > >> language > > > > >>> in the 1961 novel "Stranger in a Strange Land," she said, > "The > > > > >> basic > > > > >>> concepts are easy, but truly groking REST takes time." > > > > >>> > > > > >>> To illustrate the difference between an object-oriented > approach > > > > >> and > > > > >>> REST, she used the example of writing a program to turn a > > > > >> building's > > > > >>> lights on and off, keeping in mind that in REST the power > is in > > > > >>> sending a command to a URI. > > > > >>> > > > > >>> "A REST application to turn on and off the lights in your > building > > > > >>> will require you to design a URI for every light bulb and > then you > > > > >>> send it on/off messages," she explained. "It's not like I > have a > > > > >>> single service that manages all my light bulbs. It's a very > > > > >> different > > > > >>> approach to designing a system. And it's going to be > really hard > > > > >> for > > > > >>> developers to get their hands around it." > > > > >>> > > > > >>> Frameworks and tools for designing and building such REST > > > > >> applications > > > > >>> are coming from major vendors, especially IBM and > Microsoft, which > > > > >> are > > > > >>> making major investments in the technology, she said. It > is also > > > > >>> coming from the open source community. The new version > 2.0 of Ruby > > > > >> on > > > > >>> Rails "will make it easier to do REST Web services," > Manes said. A > > > > >>> major vendor commitment was confirmed this past week by > Gerry > > > > >> Cuomo, > > > > >>> IBM Fellow and WebSphere CTO, who said in an interview at > IBM's > > > > >> Impact > > > > >>> 2007 conference in Orlando, that Big Blue also sees REST > as the > > > > >> next > > > > >>> big thing. > > > > >>> > > > > >>> However, the problem for early adopters is that most of > the tools > > > > >>> developers will use for future REST development are still > on the > > > > >>> drawing boards, and current tooling is not ready for > REST, Manes > > > > >> said. > > > > >>> "Web services toolkits that say they do REST don't always > [do it as > > > > >>> advertised]," she said. "They do POX (plain old XML)." > > > > >>> > > > > >>> But architects and developers will not have long to wait > before > > > > >> REST > > > > >>> is "baked into frameworks," she said. "You're going to > see some > > > > >> very > > > > >>> interesting frameworks come down the line in the not too > distant > > > > >>> future," she predicted. > > > > >>> > > > > >>> In the next three years, an IT organization's willingness > to be > > > > >>> patient with early versions of REST tools and to make the > mind-leap > > > > >>> from object-oriented programming will determine where > they land on > > > > >> the > > > > >>> adoption curve, Manes said. > > > > >>> > > > > >>> "The first thing you have to figure out is whether or not > you're > > > > >> ready > > > > >>> for REST," she told her audience. "What's your developer > skill set? > > > > >>> Are they going to be comfortable working with XML? Are > they going > > > > >> to > > > > >>> be comfortable working with raw HTTP? Are they > comfortable working > > > > >>> with open source projects, experimental frameworks or > incubation > > > > >>> projects? Are they open to letting go of their object- > oriented > > > > >>> mindset? Are they willing to relinquish the productivity > frameworks > > > > >>> that are inherent in the current vendor tooling and start > working > > > > >> in a > > > > >>> more raw framework environment?" > > > > >>> > > > > >>> Any architect or IT manager answering yes to all of the > above is a > > > > >>> REST innovator in Manes book. > > > > >>> > > > > >>> "If you're ready for REST I suggest you jump on board > right away > > > > >> and > > > > >>> get ahead of the curve," she said. "You'll have to train > your > > > > >>> developers in REST principles. You'll probably want to > adopt one of > > > > >>> the new frameworks or help build one yourself to help your > > > > >> developers > > > > >>> implement RESTful applications. You definitely need to > provide > > > > >>> guidance to your people. What you want to do is work to > the point > > > > >>> where REST becomes the default for all your distributed > > > > >> applications." > > > > >>> > > > > >>> Those who are not ready to take the leap into REST need > not be too > > > > >>> concerned, she said, stressing that the advent of REST as > the > > > > >>> programming model for SOA is a matter of "when, not if.". > > > > >>> > > > > >>> "If you're not ready for REST, if your organization is > not ready to > > > > >>> jump into the innovator stage that's okay," she reassured > her > > > > >>> audience. "You're not going to get hurt. It's perfectly > reasonable > > > > >> to > > > > >>> wait two to three years for the frameworks to mature to > the point > > > > >>> where they are actually going to help you with this > process. For > > > > >> the > > > > >>> time being, you probably should continue to use SOAP and > WS-* to > > > > >> build > > > > >>> your distributed services." > > > > >> > > > > > === message truncated === > > > > > > > > > > > > > > > > > > > > > > > > > > ______________________________________________________________________ > > > > > ______________ > > > > > Fussy? Opinionated? Impossible to please? Perfect. Join > Yahoo!'s > > > > > user panel and lay it on us. http://surveylink.yahoo.com/gmrs/ > > === message truncated === > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
