Home

News: 12 Things You Should Know About REST Web Services and WOA

Bookmark and Share Get thread feed

  1. 12 Things You Should Know About REST Web Services and WOA (33 messages)

    How we develop and connect our Web sites and systems together has begun evolving more rapidly than usual in the last several years as a digital divide forms between new online software development methods versus the slow pace of evolution inside our businesses and other organizations.

    Simple and highly effective models like REST are giving rise to something known as Web-Oriented Architecture and this is driving major changes like the widespread creation of Web apps "built on the shoulders of giants" such as Amazon's S3 and the brand new Google App Engine.

    To help understand this generational change in software development, read the 12 Things You Should Know About REST and WOA.

    The twelve things are, without their attendant explanations:
    1. REST posits an interconnected information ecosystem, not an isolated set of point Web services.
    2. A focus on Design for Consumption instead of Design for Integration.
    3. REST security is egalitarian and is as secure as the Web itself.
    4. Service interaction directly by the client is a first class citizen in WOA.
    5. Service contracts are simpler and suppler in a REST model.
    6. REST strongly complements traditional SOA, if you must have it.
    7. REST and WOA enable and do not violate the principles of service-orientation.
    8. We have reached a possibly final state of deconstruction between data and function.
    9. REST drives WOA but WOA extends beyond REST.
    10. REST is deeply infused into the fabric of the Web today.
    11. REST enables an inversion of control that drives adoption and integration.
    12. REST and WOA can handle systems of arbitrary complexity and size.
    How has Web service development changed for you in the last several years?
    Reply to this

    Threaded Messages (33)

  2. Re: 12 Things You Should Know About REST Web Services and WOA[ Go to top ]

    It's time to feed
    http://emptybottle.org/bullshit/

    Guido
    Reply to this Reply to original

  3. Re: 12 Things You Should Know About REST Web Services and WOA[ Go to top ]

    We have reached a possibly final state of deconstruction between data and function.

    My magic 8 ball says "ask again later".
    Reply to this Reply to original

  4. Re: 12 Things You Should Know About REST Web Services and WOA[ Go to top ]

    We have reached a possibly final state of deconstruction between data and function.


    My magic 8 ball says "ask again later".

    Funny. Well he did say 'possibly'. His argument is somewhat valid here. If you are planning on providing a public service and want it to be used your best chance is to make it web-friendly.
    Reply to this Reply to original

  5. Re: 12 Things You Should Know About REST Web Services and WOA[ Go to top ]

    We have reached a possibly final state of deconstruction between data and function.


    My magic 8 ball says "ask again later".


    Funny. Well he did say 'possibly'.

    I'm 'possibly' the strongest man on earth. I'm 'possibly' a ten foot tall alien from Alpha Centauri.
    Reply to this Reply to original

  6. Ashamed[ Go to top ]

    I am now ashamed to have ever thought REST was cool. Thanks Dion!
    Reply to this Reply to original

  7. Re: 12 Things You Should Know About REST Web Services and WOA[ Go to top ]

    It's coming from people who call themselves analysts/architects and what not who think they can earn their living without ever writing a single line of code or actually doing anything meaningful that does something productive to their company. I actually deal with people everyday like that who waste everybody's time and confusing/worrying the ignorant management by repeating buzzwords and over analyzing shit. I think we actually have arrived into BS-OA.
    Reply to this Reply to original

  8. Re: 12 Things You Should Know About REST Web Services and WOA[ Go to top ]

    It's coming from people who call themselves analysts/architects and what not who think they can earn their living without ever writing a single line of code or actually doing anything meaningful that does something productive to their company. I actually deal with people everyday like that who waste everybody's time and confusing/worrying the ignorant management by repeating buzzwords and over analyzing shit. I think we actually have arrived into BS-OA.

    ok.
    1. Those guys actually exist. They create an architectural anti-pattern called Intellectual Violence. See here .

    2. BTW, Not all architects try to make a living without writting code.

    William Martinez.
    Reply to this Reply to original

  9. Why the cynicism?[ Go to top ]

    The backlash against REST and Web 2.0 on this thread is surprising.

    The Web 2.0 buzzword generator linked to by Guido proves nothing, except that randomly arranged nouns, verbs and adjectives sometimes produce coherent phrases. If this is the depth of your thinking on current trends in the software industry (Web 2.0, REST, etc.) I feel sorry for you.

    Also why do you assume that these concepts/models originate from non-coding architects? There is significant interest in REST today in the Java community. Take JSR-311, the Java API for RESTful Web Services for instance.

    Dion has put together an interesting and informative article on Web architecture that I feel should not be dismissed so casually. If anything, we need more research and discussion on REST to help everyone gain a better understanding of it.

    Instead of cynicism, wouldn't it be a better use of time to try to think beyond the buzzwords to understand some of the concepts that inspire this movement?

    Instead of dismissing ideas generally, why not raise specific objections? What points do you disagree with?
    Reply to this Reply to original

  10. Re: Why the cynicism?[ Go to top ]

    Instead of dismissing ideas generally, why not raise specific objections? What points do you disagree with?

    I think statements like the following:

    "REST and WOA can handle systems of arbitrary complexity and size."

    That are stated as fact even though there is no way to prove them spawns cynicism. How many times has some technology or approach been touted as the 'possibly final' solution? It reminds me of a line from an old comedy skit: "the wheelbarrow: mankind's ultimate and final achievement."
    Reply to this Reply to original

  11. Re: Why the cynicism?[ Go to top ]

    Several points in the article are well made. In fact I think that REST goes way beyond any WSDL/SOAP approach for the definition of web services.

    It is just that everyone here and everywhere is so bored of hearing buzzwords after buzzwords. Please let this BS to the marketing guys. This is a technical forum!
    Reply to this Reply to original

  12. Re: Why the cynicism?[ Go to top ]

    The backlash against REST and Web 2.0 on this thread is surprising.
    ...
    Also why do you assume that these concepts/models originate from non-coding architects? There is significant interest in REST today in the Java community. ...
    Dion has put together an interesting and informative article on Web architecture that I feel should not be dismissed so casually. If anything, we need more research and discussion on REST to help everyone gain a better understanding of it.
    ...

    1. I think the backlash is against the buzzwordy look of the list, not REST or Web 2.0

    2. There is no such thing as a non-coding architects. You may have very experienced coders that stop coding to become document generators, or non-skilled coders that were put to document before they break something. But they only are misnomers of architecture. Real architects do code, and they do it frequently to prove it can be done!

    3. Good on Dion. But the article may not be for development, is more written as a PhD dissertation. Still, some points may be fun to discuss.

    William Martinez
    Reply to this Reply to original

  13. Re: Why the cynicism?[ Go to top ]

    The backlash against REST and Web 2.0 on this thread is surprising.
    First, please (repeat, please) don't read my post as being hostile against you or anyone else.
    Here I speak for myself (my post). I am not against REST,
    I simply think that it is nothing else but hot water discovery.
    Careful HTTP RFC reading will reveal exactly the same things.


    The Web 2.0 buzzword generator linked to by Guido proves nothing, except that randomly arranged nouns, verbs and adjectives sometimes produce coherent phrases.
    The link was not there to prove anything. I simply meant that
    the 12 points could have well been the product of the generator: fried air. (Don't know if the term is known out of Italy)
    If this is the depth of your thinking on current trends in the software industry (Web 2.0, REST, etc.) I feel sorry for you.
    Do you really think that the 12 points have a relevant depth ?
    Trends in SW industry ?
    Do you mean a way to sell again an old product with a new dress ?
    Do you mean a way to give new buzzwords to pseudo-consultants whose only goal is selling products instead of solving customers'problems ?
    If you mean something else please clarify.


    Also why do you assume that these concepts/models originate from non-coding architects? There is significant interest in REST today in the Java community. Take JSR-311, the Java API for RESTful Web Services for instance.
    This really means nothing.
    I getting old, so I pose uncomfortable questions to myself:
    is there a real (technical) need for the spec or, again, the aim is to give a sort of "standard" background for the restyled old products ?
    Several years have passed since JAX-RPC/JAX-WS and still there is no (serious) server-side portability layer, in spite of the experience gained with different technologies.
    Do we really need another immature spec ?


    Dion has put together an interesting and informative article on Web architecture that I feel should not be dismissed so casually. If anything, we need more research and discussion on REST to help everyone gain a better understanding of it.

    Instead of cynicism, wouldn't it be a better use of time to try to think beyond the buzzwords to understand some of the concepts that inspire this movement?

    Instead of dismissing ideas generally, why not raise specific objections? What points do you disagree with?
    See above.

    Guido
    Reply to this Reply to original

  14. Re: Why the cynicism?[ Go to top ]

    The backlash against REST and Web 2.0 on this thread is surprising.

    The backlash is probably more against bullshit bingo than against anything else. As for REST (btw. What *is* Web 2.0 other than what whoever you talk to wants it to be.), I too find it interesting. On the other hand, I find it hard to believe that it has meaningful use, outside some very specific cases. This it not to say it will not be successful of course.

    Take AOPish programming models which are now widely successful, but which fail to cash in on their original promise (less code, real separation from "core" code and concerns etc., AOP advices really independent from their targets).
    Reply to this Reply to original

  15. Re: Why the cynicism?[ Go to top ]

    The backlash against REST and Web 2.0 on this thread is surprising.


    The backlash is probably more against bullshit bingo than against anything else. As for REST (btw. What *is* Web 2.0 other than what whoever you talk to wants it to be.), I too find it interesting. On the other hand, I find it hard to believe that it has meaningful use, outside some very specific cases.

    I think REST is a much more solid platform than SOAP and WS*:

    http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/

    However it's become a religion. If anyone suggests something like a standard machine readable document for defining a rest interface vaguely similar to what WSDL provides but much, much better, a restafarian will invariably go apeshit because REST does 'need' anything like that and it's perfect as-is.
    Reply to this Reply to original

  16. Re: Why the cynicism?[ Go to top ]

    If anyone suggests something like a standard machine readable document for defining a rest interface vaguely similar to what WSDL provides but much, much better, a restafarian will invariably go apeshit because REST does 'need' anything like that and it's perfect as-is.

    Sorry, James, I did exactly that in my blog several months ago. The problem is that REST is a style that can be used for a solution. That style, to work, does not need a service definition because it is not a service oriented style.

    Now, you can use it to define a service, in which case you do need a definition. Common REST-followers approach is to communicate this definition using a human-readable document (an html, a word document, a phone call). You can use another XML document (actually you do if you use XSD). You can reinvent the wheel or adapt an standard. I actually suggested WSDL 2.0 since it now has HTTP detail and allows you define the interactions at POST/PUT/GET level.

    Probably REST coders will not like the idea. They actually don't need the definition. But it is not REST what we are talking here, it is the solution, and for enterprise solutions where thousands of dollars are moving through the web, they wont like the only definition is on the developer's head, right?

    William Martinez Pomares
    Reply to this Reply to original

  17. Re: Why the cynicism?[ Go to top ]

    If anyone suggests something like a standard machine readable document for defining a rest interface vaguely similar to what WSDL provides but much, much better, a restafarian will invariably go apeshit because REST does 'need' anything like that and it's perfect as-is.


    Sorry, James, I did exactly that in my blog several months ago. The problem is that REST is a style that can be used for a solution. That style, to work, does not need a service definition because it is not a service oriented style.

    Now, you can use it to define a service, in which case you do need a definition. Common REST-followers approach is to communicate this definition using a human-readable document (an html, a word document, a phone call). You can use another XML document (actually you do if you use XSD). You can reinvent the wheel or adapt an standard. I actually suggested WSDL 2.0 since it now has HTTP detail and allows you define the interactions at POST/PUT/GET level.

    I didn't see the blog (that I am aware of) but if the above is your position, I am in total agreement. I don't REST (or a similar approach) should require a definition but it's something that would be useful in a number of cases. A really useful standard would also define how you retrieve this document for a given domain or subdomain preferably with a GET.

    I mentioned that WSDL 2.0 supports REST in a recent thread and I was told this was a horrible solution. OK, I'll humor that but what other alternatives are there? I'm all for a simpler approach if someone can just tell me what it is.
    Reply to this Reply to original

  18. Re: Why the cynicism?[ Go to top ]

    I think REST is a much more solid platform than SOAP and WS*

    I am not sure this is entirely true. And I do not believe it is the right question. The right question is probably: Is REST superior (in general) to xml-over-http technologies where the verb is not part of the protocol and the entity is not part of the URL.

    A lot of the use cases I work with involve manipulations to numerous entities in a single transaction. The classic case is transfer money from one account to another and create a change of ownership on something (say a security) within the same transaction. I find that rather complicated and unnatural to formulate using a RESTful approach.

    The one thing I find very intriguing using REST is the potential to pass around "things" (essentially object references) by passing the URLs.

    But I think if one would really want to leverage this using an "enterprise class" (read transactional, secure, redundant etc.) approach REST would need to be underpinned with so many services that we'd end up with something very much like Corba in the end anyway.
    Reply to this Reply to original

  19. Re: Why the cynicism?[ Go to top ]

    I think REST is a much more solid platform than SOAP and WS*


    I am not sure this is entirely true. And I do not believe it is the right question. The right question is probably: Is REST superior (in general) to xml-over-http technologies where the verb is not part of the protocol and the entity is not part of the URL.

    I haven't really been clear but this is one of my problems with orthodox restafarians. The idea that everything has to be represented as a resource seems pretty absurd to me. It often does make sense but to think of things that way but the reality is that whenever you are working with a distributed environment, everything is just a message.

    In a nutshell, I agree that other xml-over-http approaches are also valid along side a REST approach. It just depends on what you need to do. I don't have any qualms with hybrid styles either unless someone can explain why I should.

    But I definitely think that SOAP and WS* are not worth the trouble and don't merit continuing outlays of corporate resources if they can be avoided.
    Reply to this Reply to original

  20. Re: Why the cynicism?[ Go to top ]

    Actually, James, it shouldn't be just simpler but also, hopefully, standard and accepted, so everybody's work on reading and implementing is reduced.

    Sorry, I misunderstood your post, I thought you were the one to go "Apeshit" as part of the orthodox restafarians. It seems you are not one of them, right?


    William Martinez Pomares.
    Architect's Thoughts
    Reply to this Reply to original

  21. So encapsulation was actually bad?[ Go to top ]

    Data decoupled or decapitated?
    Reply to this Reply to original

  22. Re: So encapsulation was actually bad?[ Go to top ]

    Encapsulation is good when you are coding algorythms that run in one process. Object-oriented approach and encapsulation is good for coding processes, implementing components, implementing GUIs and the like. It is when you use an object-oriente paradigm with a distributed system, i.e. you objectify the interaction of components distributed across the web, that the paradigm is no longer a winner. Coding benefits from encapsulation, architectures usually don't.
    Reply to this Reply to original

  23. Re: So encapsulation was actually bad?[ Go to top ]

    Encapsulation is good when you are coding algorythms that run in one process. Object-oriented approach and encapsulation is good for coding processes, implementing components, implementing GUIs and the like. It is when you use an object-oriente paradigm with a distributed system, i.e. you objectify the interaction of components distributed across the web, that the paradigm is no longer a winner. Coding benefits from encapsulation, architectures usually don't.

    Let's not talk about encapsulation, but information hiding. The first one is for objects, the latter one for structures. Actually, IH was coined and understood as a fundamental principle by Parnas, even before OO was invented.

    So, applying IH to architectural structures is not "objectify" the thing, but to reduce coupling and refactoring cost.

    William Martinez.
    Reply to this Reply to original

  24. Re: 12 Things You Should Know About REST Web Services and WOA[ Go to top ]

    Took the time to read it. Plenty I can agree with but maybe this board isn't the correct audience? Seems pretty manager-focused with the buzz-word overkill.

    One thing I laugh at is the concept of a "traditional SOA" (he uses the word "traditional" 13 times in the article). Excuse me? I know my grandpa was whittling SOA out of oak branches in 1940 but is it old enough to be referred to as traditional?

    Thomas Erl's SOA bible was published late in 2005. You mean the junk I learned in those seminars I was encouraged to go to have already gone the way of the do do?
    Reply to this Reply to original

  25. Re: 12 Things You Should Know About REST Web Services and WOA[ Go to top ]

    Took the time to read it. Plenty I can agree with but maybe this board isn't the correct audience? Seems pretty manager-focused with the buzz-word overkill.

    One thing I laugh at is the concept of a "traditional SOA" (he uses the word "traditional" 13 times in the article). Excuse me? I know my grandpa was whittling SOA out of oak branches in 1940 but is it old enough to be referred to as traditional?

    Thomas Erl's SOA bible was published late in 2005. You mean the junk I learned in those seminars I was encouraged to go to have already gone the way of the do do?

    Yeah, it was kind of weird to me that on his time line the SOA era appears to be in the 1990s. Maybe I'm just really behind the times but I don't recall hearing about SOA until the aughts.
    Reply to this Reply to original

  26. Re: 12 Things You Should Know About REST Web Services and WOA[ Go to top ]

    Some of us were practicing what is now called SOA in the early and mid-nineties. The term didn't exist yet though. However, all the important concepts were there: messages, component-based construction, service concepts, services as use case realizations, etc. Much of it was done by component-based guys borrowing from the 3-tier world in order to improve performance in a distributed environment - me for instance. I used Tuxedo with C and later C++ and later some CORBA. The better performing CORBA implementations I saw implemented services instead of objects (with getters/setters and copy helpers).

    I credit Unix System Labs (creators of Tuxedo) for 3-tier architectures and the service style. Tuxedo supported message buffers with text schemas (FML and field table files) pretty early on. With that you could do a lot of what we do today with web services but much faster. The drawback was the proprietary protocol and clients you had to pay for.

    What USL didn't bring to the table was the component-based construction and packaging and the grouping of service operations around a common domain so a single process represented what we think of today as a service in the SOA style. That came (to me at least) from OO and component-based development.

    So, there is “traditional SOA”. Guys like Thomas Erl arrived relatively late in the game. His contribution from what I can see is not SOA as a technical solution but the linking of SOA in the technical realm to the rest of the enterprise – making the enterprise think SOA. It’s an important contribution and is necessary in order to capture a lot of SOA’s ROI potential.
    Reply to this Reply to original

  27. Re: 12 Things You Should Know About REST Web Services and WOA[ Go to top ]

    Some of us were practicing what is now called SOA in the early and mid-nineties.

    I could show evidence that this was being done much earlier than that. Much of EDI is structured as services and has been used as early as the 70's, maybe even before that.

    In my opinion, the big misconception of SOA is that it's a technology in the normal sense of the word. The other misconception is that SOA is new. It's not, it's just a term applied to a proven strategy. So saying that the 90's was the age of SOA just because some people were doing it doesn't make sense. We don't consider the late 19th century the age of the automobile even though people were driving them in that time period.

    One of the things about this article that seems not only like BS but just plain wrong is this claim that WOA (the definition of which is unclear to me) is a super set of SOA. My understanding is that Web implies HTTP and SOA isn't constrained to any particular protocol or set of protocols. It's an approach, not an implementation. Constraining SOA to the web is limiting SOA. Perhaps WOA has approaches that are outside of those that SOA has but that's means there's an intersection, where neither is a superset of the other. This claim and others make me feel that this author doesn't really understand SOA.
    Reply to this Reply to original

  28. Re: 12 Things You Should Know About REST Web Services and WOA[ Go to top ]

    One of the things about this article that seems not only like BS but just plain wrong is this claim that WOA (the definition of which is unclear to me) is a super set of SOA.

    I looked at this again and I guess I read into something or mixed up some sections. So this comment is a little off track.

    But I'd still like to see a definition of WOA.
    Reply to this Reply to original

  29. Re: 12 Things You Should Know About REST Web Services and WOA[ Go to top ]

    Perhaps WOA has approaches that are outside of those that SOA has but that's means there's an intersection, where neither is a superset of the other. This claim and others make me feel that this author doesn't really understand SOA.

    I agree. WOA and SOA seem to have some intersection at some level even beyond the technology, but they are attacking different problem spaces. Distinguishing between the 2 is useful because neither style is necessarily the best choice for everything. Unfortunately the article makes a lot of sweeping unsupported statements. For example, it is silly to say that REST contracts are simpler. Your contract has the complexity you require. Your contract is not just your message format and the fact that some people write brittle contracts with WSDL/SOAP reflects on their skills not on inherent technology differences.

    I think that the article works better as an observation about how (some) people think and perceive what applications are than it does as a history of technology evolution or a technical comparison of SOA and WOA. Even so it has its time lines wrong. As you pointed out earlier, SOA didn't get significant mind share until this decade.

    Now some people think that SOA as they perceive it may be overkill for some applications where my perception is that people are often confusing the technology they're using with the style. Nevertheless, it is true that what the author describes as WOA is sometimes a better approach than SOA as most of us understand it so maybe we'll see WOA being added to the toolbox, next to the hammer.
    Reply to this Reply to original

  30. Re: 12 Things You Should Know About REST Web Services and WOA[ Go to top ]

    Now some people think that SOA as they perceive it may be overkill for some applications where my perception is that people are often confusing the technology they're using with the style. Nevertheless, it is true that what the author describes as WOA is sometimes a better approach than SOA as most of us understand it so maybe we'll see WOA being added to the toolbox, next to the hammer.

    Just to be clear, I'm a huge fan of the basic premise of REST, that is, use the existing HTTP protocol without a lot of redundant (and generally overcomplicated) fluff on top.

    What I have little interest in is kool-aid. I think that it's inevitable that this paradigm (or off-shoot of it) will become the norm. Articles like this, while containing some useful info, are more likely to hamper acceptance by creating buzzword-backlash just like what has happened to SOA.

    When IBM has TV commercials featuring buzzword bingo as the punchline, you know it's reached critical mass.
    Reply to this Reply to original

  31. Hey Kool-aid! (crash)[ Go to top ]

    When IBM has TV commercials featuring buzzword bingo as the punchline, you know it's reached critical mass.

    Well now they can sell two tiers of the WebSphere Enterprise Service Bus SOA-enabled and for a little more cash WOA-enabled.

    I pretty much concur with the thread that the article was a bit too "hype". Maybe its purpose was more to advertise for the webinar at the bottom?

    There is a new article today on "What is WOA?". Will give that one a read and see if it is a bit more constrained.
    Reply to this Reply to original

  32. Re: Hey Kool-aid! (crash)[ Go to top ]

    http://hinchcliffe.org/archive/2008/02/27/16617.aspx

    Much better article by the same author.

    In a way, I think WOA is an unfortunate acronym because of its relationship to SOA. Too confusing. Using proven web-technology as your SOA implementation strategy is a great idea, just need to come up with a buzzword that doesn't confuse what has already come. Sure you could describe the web technologies as an architecture but that just proves how fuzzy the term "architecture" in software is.

    And I hate the term "mashup", but what can you do?
    Reply to this Reply to original

  33. Re: 12 Things You Should Know About REST Web Services and WOA[ Go to top ]

    Totally agree with William's point of view.

    The Article has its points. It is totally clear that there is a confusion of what actually SOA means (still the old misconception of SOA = Web Services and WSDL is the demon in lingerie) and about what simplicity at REST means.

    WOA as a momentum since now talking about desktop applications may mean you are outdated! And don't get me wrong: WOA is far more that just a web interface (explain that to managers), but if it takes the same road as SOA, you will find vendors claiming to give you WOA in a can when you actually get a box full of web interface templates.

    Want me to stretch the concept? In WOA you can have resources in the web space, accessible by name (URL). A Web Service is one of such resources, so web services can have a place in WOA. Funny, hu?

    William Martinez Pomares
    Reply to this Reply to original

  34. Re: 12 Things You Should Know About REST Web Services and WOA[ Go to top ]

    Totally agree with William's point of view.

    The Article has its points. It is totally clear that there is a confusion of what actually SOA means (still the old misconception of SOA = Web Services and WSDL is the demon in lingerie) and about what simplicity at REST means.

    WOA as a momentum since now talking about desktop applications may mean you are outdated! And don't get me wrong: WOA is far more that just a web interface (explain that to managers), but if it takes the same road as SOA, you will find vendors claiming to give you WOA in a can when you actually get a box full of web interface templates.

    Want me to stretch the concept? In WOA you can have resources in the web space, accessible by name (URL). A Web Service is one of such resources, so web services can have a place in WOA. Funny, hu?

    William Martinez Pomares

    There is no such WOA. What is WOA? In his article, he can't explain what a real WOA is. An architecture is a skeleton that holds one or more philosophy about one thing making up a framework that is abstract enough as root to construct the hierarchy.

    Web is a technology in high level, low level is just a protocol. Web could be the technology of constructing SOA. Even though you may use Web protocol to design your entire application, it is only a Web Application. And in this design, if you have used abstraction to interoperate your components, that is not WOA, that is actually SOA.
    Reply to this Reply to original