Discussions

News: A RESTful Core for Web-like Application Flexibility - Part 1

  1. Representational State Transfer (REST) computing offers developers and applications a number of advantages, including simplicity and flexibility in running applications. The growing interest in REST demonstrates that it has the potential to address issues in building and maintaining applications through its use of abstraction of resources. Tom Hicks and Randy Kahle begin this series on RESTful computing with the surprising topic of binding. Read the Article

    Threaded Messages (110)

  2. Extreme[ Go to top ]

    As interest in REST and RESTful design increases, we will see creative technologies aimed at supporting this approach. Some will be RESTful only at the edges and will miss the full benefits found by taking REST to the core of new applications. In subsequent articles we will explore an approach to pushing REST all the way to the core of new applications and how the sought-after economic benefits are, in fact, realized.
    There are times when closer coupling are better and not totally bad and times when looser coupling makes sense. I believe the snippet above from the article, when in the wrong hands will prove to be disastrous. I cant even keep count anymore how many times I've encountered some Pimple faced kid or bearded grandpa that takes some text about architecture and design and applies it to extremity. Improvements/Optimization is about applying the right solution to the right problem in the right scenario at the right time. I just dont see how the so called "economic benefits" can be realized just by pushing RESTful approaches anytime, anywhere. Dont provide the gun _before_ educating the user when is the right time and place to use it. We dont need to "push" RESTful approaches to core applications ALL the time.
  3. Inaccurte and Mis-guided[ Go to top ]

    This article starts with some inaccurate premises and is completely misguided. "After all, REST is a "high level" idea that originated from a post hoc analysis of why the World Wide Web works so well [1]" Not true. Refer to the abstract of [1] which states "REST has been used to guide the design and development of the architecture for the modern Web." The so-called binding this article is talking about is achieved through URIs and other infrastructure on the web. It is fine if the authors want to introduce a new URI scheme and a new uniform interface (i.e. new verbs), but this article does not make a case for doing so. TSS should spend some time before publishing articles like this. I wonder if this article was reviewed at all. Subbu Allamaraju http://subbu.org
  4. This article starts with some inaccurate premises and is completely misguided.

    "After all, REST is a "high level" idea that originated from a post hoc analysis of why the World Wide Web works so well [1]"

    Not true.
    I'm pretty sure it is accurate.
    The so-called binding this article is talking about is achieved through URIs and other infrastructure on the web. It is fine if the authors want to introduce a new URI scheme and a new uniform interface (i.e. new verbs), but this article does not make a case for doing so.
    I really have no idea what you are talking about. Who is suggesting new verbs? REST uses standard HTTP operations and these authors aren't suggesting anything new. It's merely explaining something that is already in use.
  5. Re: Inaccurte and Mis-guided[ Go to top ]

    Who is suggesting new verbs? REST uses standard HTTP operations and these authors aren't suggesting anything new. It's merely explaining something that is already in use.
    Am I misreading this part, too?
    For our system, let's introduce a slightly modified set of verbs: SOURCE, SINK, NEW, EXISTS, and DELETE.
  6. Re: Inaccurte and Mis-guided[ Go to top ]

    Who is suggesting new verbs? REST uses standard HTTP operations and these authors aren't suggesting anything new. It's merely explaining something that is already in use.

    Am I misreading this part, too?
    For our system, let's introduce a slightly modified set of verbs: SOURCE, SINK, NEW, EXISTS, and DELETE.
    Sorry I was mistaken and I'll have to concede to Subbu on this point. It was my understanding that REST used standard verbs and I missed this part. It doesn't seem to be a big part of the article and it's never explained why this is done. Perhaps that's in part 2? I'm not a REST expert so I can't say whether this is a proper REST approach or not but I've never heard anything about creating custom verbs like this in REST approaches. The big thing you always hear or read about is how all you need is the four main verbs: GET, PUT, POST, and DELETE
  7. Uniform interface[ Go to top ]

    The big thing you always hear or read about is how all you need is the four main verbs: GET, PUT, POST, and DELETE
    REST is not limited to CRUD as in GET, PUT, POST and DELETE. Those are verbs in HTTP 1.1. As far as REST is concerned, the emphasis is on keeping the interface uniform so that clients, and interactions between clients and servers can remain generic.
  8. Re: Uniform interface[ Go to top ]

    The big thing you always hear or read about is how all you need is the four main verbs: GET, PUT, POST, and DELETE


    REST is not limited to CRUD as in GET, PUT, POST and DELETE.
    Reference please? I'll go first: http://en.wikipedia.org/wiki/Representational_State_Transfer "The most important HTTP methods are POST, GET, PUT and DELETE. These are often compared with the CREATE, READ, UPDATE, DELETE (CRUD) operations associated with database technologies" http://www.infoq.com/articles/rest-introduction Under the section titled: "Use standard methods" "It knows what to do with it because every resource supports the same interface, the same set of methods (or operations, if you prefer). HTTP calls these verbs, and in addition to the two everyone knows (GET and POST), the set of standard methods includes PUT, DELETE, HEAD and OPTIONS." HEAD and OPTIONS are often suggested for use for getting information about a service but this seems to be mostly theoretical from what I see.
  9. Re: Uniform interface[ Go to top ]

    REST is an architecture style, and suggests the uniform interface constraint for the sake of generality. HTTP on the other hand is a "particular uniform interface. Even the wikipedia reference is clear about it. It is talking about a particular example (i.e. HTTP). REST, as an architecture style, does not define the interface itself. You are free to define a uniform interface with verbs such as do, go, come, sleep etc. The emphasis is on the uniformity of the interface. Want a reference? Read Roy Fielding's thesis.
  10. Re: Uniform interface[ Go to top ]

    REST is an architecture style, and suggests the uniform interface constraint for the sake of generality. HTTP on the other hand is a "particular uniform interface. Even the wikipedia reference is clear about it. It is talking about a particular example (i.e. HTTP). REST, as an architecture style, does not define the interface itself. You are free to define a uniform interface with verbs such as do, go, come, sleep etc. The emphasis is on the uniformity of the interface.
    What I originally said was that what is commonly argued is that you only 'need' the four verbs GET, PUT, POST and DELETE. Saying that you can have more (which I already knew BTW) isn't a counter argument to my point in any way. You haven't shown a lick of evidence to the contrary.
    Want a reference? Read Roy Fielding's thesis.
    This is a cop-out. If you know these things you should be able to explain them yourself.
  11. Re: Uniform interface[ Go to top ]

    You WERE asking for a reference. See your comment before calling it a "cop-out". Q.E.D. No point in continuing this thread.
  12. Re: Uniform interface[ Go to top ]

    You WERE asking for a reference. See your comment before calling it a "cop-out".

    Q.E.D. No point in continuing this thread.
    There was a reference. You just keep pointing to document that doesn't make your case. Repetition isn't proof. If you can show me where in that document he makes your case that would be different. And you have made several accusations that I was being personal. I was not. I only stated what the tone of your posts suggested to me.
  13. This article starts with some inaccurate premises and is completely misguided.

    "After all, REST is a "high level" idea that originated from a post hoc analysis of why the World Wide Web works so well [1]"

    Not true. Refer to the abstract of [1] which states

    "REST has been used to guide the design and development of the architecture for the modern Web."
    I am not sure which premise Mr. Allamaraju feels is inaccurate; that REST is a high-level idea or that it originated from a post hoc analysis. Roy Felding's thesis was published in 2000. Surely, Mr. Allamaraju will acknowledge that the Web was well-established before that time. Therefore, Dr. Felding's analysis and coinage of the term REST was clearly "after the event" (in Latin "post hoc"). The principles Dr. Felding was describing and categorizing had, of course, long been used to guide the design and development of the Web.
  14. Though it was published in 2000, it was in the works for years before that. Please don't conclude that it is based on post-hoc analysis without asserting the same from Roy.
  15. Though it was published in 2000, it was in the works for years before that. Please don't conclude that it is based on post-hoc analysis without asserting the same from Roy.
    I apologize if I am mistaken but it seems from your posts that you had never heard of REST before seeing this article. If that's the case, I think it's improper for you to contradict what is widely considered to be true. All you've offered for evidence is a quote from a paper that I think you have misinterpreted. The term REST was introduced by that paper. I think what Fielding is saying is that people were using this architecture for years before he coined the term and explained it in formal terms. In which case the statement that it was post-hoc analysis is absolutely accurate.
  16. See, e.g. the thread http://lists.xml.org/archives/xml-dev/200201/threads.html#01780. While I can't make claims either way, my conclusion is that the underlying concepts were evolving simultaneously, and it would be too simplistic to conclude that REST was purely based on post hoc analysis. Subbu
  17. See, e.g. the thread http://lists.xml.org/archives/xml-dev/200201/threads.html#01780. While I can't make claims either way, my conclusion is that the underlying concepts were evolving simultaneously, and it would be too simplistic to conclude that REST was purely based on post hoc analysis.

    Subbu
    From that thread: http://lists.xml.org/archives/xml-dev/200201/msg01276.html "In the case of the WWW, I *very* much doubt that it was designed with all the tradeoffs in mind.... I watched it, and participated in it's development. If there is any person that claims they knew all we know now in 1993 (after the WWW per se was designed), and made design decisions based on tradeoffs fed by that knowledge, I'd like them to stand up *now* so I can call them a liar to their face." In any event the dissertation was written in 2000 and the author says it is a formalization of the principles that made the web work well. What exactly about that conflicts with the description "post-hoc analysis"? Are you suggesting that people from the years 1993-2000 were reading this document through their crystal balls?
  18. James Two comments. Firstly, there is no need to tear this apart further. The fact is that these things were in development at around the same time, and I stand by that. The reference here is not WWW, but HTTP and URIs. Secondly, please don't make statements such as "you had never heard of REST before seeing this article". We don't know each other, so let's leave it at that. Subbu http://subbu.org
  19. James

    Two comments. Firstly, there is no need to tear this apart further. The fact is that these things were in development at around the same time, and I stand by that.
    This is where you seem kind of confused. What two things? REST is the formal description of the architecture of the web. What are the 'things' you are referring to?
  20. This is where you seem kind of confused.
    There you go again. The two things I am talking about are HTTP and URIs. Read the references cited, and you shall find the answers.
  21. This is where you seem kind of confused.


    There you go again.

    The two things I am talking about are HTTP and URIs.
    And what exactly does that have to do with whether REST was created with post-hoc analysis of the web?
  22. Apologies to Dr. Fielding[ Go to top ]

    Oops, sorry, meant to type "Fielding" not "Felding"
  23. Just use Groovy (or whatever)[ Go to top ]

    If the author wants to discard all of Java's static type safety, why is he using Java at all? He also talks about clients invoking services without knowing what the exact implementation is, but we've been doing this for years with factories and dependency injection. For communication between applications (or systems, subsystems, services, domains or whatever you want to call your configuration management boundaries) there are lots of benefits to loose coupling. Within an application you get lots of benefits from tight coupling. Lets keep REST where it belongs.
  24. Like a Box of Chocolates[ Go to top ]

    To overcome the problems of strong type binding, we will allow our system much more freedom in the handling of resource representations.
    The key idea is that the client and the service endpoint will not need to agree on the type of the returned representation. If the client does not specify a return type, then the endpoint is free to return any type it chooses. If the client does specify a return type but the endpoint is not able to return that type, it will still return some representation.
    That makes programming so much more fun. "You might not get what you asked for, but you'll always get something..." Isn't there a quote somewhere about asking for bread and getting a stone?
  25. Re: Like a Box of Chocolates[ Go to top ]

    To overcome the problems of strong type binding, we will allow our system much more freedom in the handling of resource representations.

    The key idea is that the client and the service endpoint will not need to agree on the type of the returned representation. If the client does not specify a return type, then the endpoint is free to return any type it chooses. If the client does specify a return type but the endpoint is not able to return that type, it will still return some representation.

    That makes programming so much more fun. "You might not get what you asked for, but you'll always get something..." Isn't there a quote somewhere about asking for bread and getting a stone?
    I've come across this recently (although in a 95% java system) - effectively someone completely misunderstood and bastardized the concept of polymorphism, inverted it and created a whole new fun world of potential accidents waiting to happen (that most of the time, eventually do happen). Defining clear interfaces and return-types is fundamental to almost ANY software development, the idea if flexibility lies on knowing what you get back (or knowing roughly what you get back, like some sort of nutrition and not stones), but not needing to know the details of how what you get back is provided. Like the previous poster said: if this isn't the case, you might end up getting back stones when you asked for bread, what use is that?
  26. Re: Like a Box of Chocolates[ Go to top ]

    Like the previous poster said: if this isn't the case, you might end up getting back stones when you asked for bread, what use is that?
    Hmm, but if you get back Jenna Jameson photo maybe is not that bad ;-) Guido
  27. Re: Like a Box of Chocolates[ Go to top ]

    Like the previous poster said: if this isn't the case, you might end up getting back stones when you asked for bread, what use is that?

    Hmm,
    but if you get back Jenna Jameson photo maybe is not that bad ;-)

    Guido
    I could make a very inappropriate joke about "Jenna Jameson" and "eating" here, but I'll avoid it. :D
  28. Re: Like a Box of Chocolates[ Go to top ]

    Maybe the paragraph was misleading or incomplete. What I intended to say was that a client always gets what they asked for or an exception is thrown indicating that the representation type is not available. If a client does not care what the type of the representation is (XML, JSON, List, Customer class, etc.) then they can make a request without specifying the returned representation type. The key point, however, is in the cases when a client does specify the returned type and a mismatch occurs between the client and the endpoint. In this case the Intermediary can step in and request a service to transform the type. This type transformation occurs transparently to both the client and the endpoint. The benefit is that one can create an application in which some parts "talk" JSON and others "talk" XML and they will work together without knowing that type transformations are occurring. It is also important to note that I'm talking about the type of the returned representation and not the information itself. If a client requests "resource:/customers/" they will get that information - so they really are getting what they asked for - the only thing we are discussing here is the type or physical form of that information.
  29. Re: Like a Box of Chocolates[ Go to top ]

    To overcome the problems of strong type binding, we will allow our system much more freedom in the handling of resource representations.

    The key idea is that the client and the service endpoint will not need to agree on the type of the returned representation. If the client does not specify a return type, then the endpoint is free to return any type it chooses. If the client does specify a return type but the endpoint is not able to return that type, it will still return some representation.

    That makes programming so much more fun. "You might not get what you asked for, but you'll always get something..." Isn't there a quote somewhere about asking for bread and getting a stone?
    I apologize....we obviously didn't explain the concept of transreptors well enough. A transreptor does not return a stone for bread, it merely allows the client to ask for a certain form of bread (dinner roll, baugette, loaf, etc). A bit more explanation: 1) The client asks for information in a specific type of representation (call this type X), 2) It's asking the Intermediary, who forwards the request to the endpoint, 3) The endpoint may not be able to return the requested type (many endpoints, in fact, may be written to return one and only one form of information), 4) The endpoint returns the requested type if it can, else it just returns the information in the form it knows how to return (call this type Y), 5) The endpoint returns the information to the Intermediary, 6) If the information from the endpoint is not in the type requested by the client (type X) the Intermediary searches for a transreptor which knows how to turn type X into type Y, 7) If the Intermediary finds an appropriate transreptor, it calls the transreptor to perform the transformation. Note that this call is transparent to both the client and the endpoint, 8) If the transreptor succeeds, the Intermediary returns the result of transreption back to the client, 9) If the Intermediary could not locate an appropriate transreptor (X -> Y) or if the transreptor fails, an error is returned to the client (i.e. it says "sorry, I couldn't provide the information in the form you requested"). So, we are never talking about returning arbitrary information, nor information which is not what the client requested in the first place.
  30. Well, the first half of the article is nothing really new. I agree that disk space and bandwidth are cheap nowadays, but time is not. And wasting time reading about how a browser gets the result from a webserver in the hope of finding some brilliant ideas to save the world is really too much. Then happens the magic. Let's put an intermediary between the client and the server to solve all the data representation discrepancies. As it is described in the article, at least in my understanding, this component is already present in a web browser. In fact, you have a certain number of "natively" supported data representations that allow the browser to automatically render data received (and to do that the specific renderer has a strict contract with the producer!!!) and a default option in case of unsupported representation (save to disk). Anyway, the intermediary solution isn't that different from a mix of the mediator and adapter pattern (GoF) and how the whole discussion is related to REST is a mistery to me. But at the end of the article is stated that
    As interest in REST and RESTful design increases
    Hmm, maybe in the consultant companies. Guido
  31. I think the focus of the potential malleability of REST style services is a disservice to the REST approach. Services that change or disappear at any time without warning only seem like a good idea to the uninitiated. No real world web service can just change without warning and not cause havoc. In fact, services are often set in stone. The only way to change them is to create a new version and clients migrate. The real value of REST is, IMO, the much simplified approach over WS*. But until REST has a widely adopted IDL and some toll support around it, I doubt it will become a major force in the 'enterprise' space.
  32. But until REST has a widely adopted IDL and some toll support around it, I doubt it will become a major force in the 'enterprise' space.
    IDL = RFC2616 tool support = java.net.URL, Apache HttpClient, Java Servlet ... That's the real reason why REST won't be "a major force in the enterprise space" (read: big bucks can be made selling related products) - the "core" REST doesn't need new tools, while "extensions" are easily recognized as vendor-specific.
  33. But until REST has a widely adopted IDL and some toll support around it, I doubt it will become a major force in the 'enterprise' space.
    IDL = RFC2616
    This is exactly the kind of attitude I am referring to. There's a Restafarian dogma that no IDL is needed. The HTTP protocol is in no way enough. It doesn't answer any of the following: How do you structure your resource paths? What does the structure of the message for a given type of resource look like? (no, XML, JSON, etc. are not answers). Where do I find human documentation for the services? Who should I contact with questions or issues? There are surely more. But as long as the REST community keeps putting it's hands over it's ears and yelling "LALALALALALALA!" they will remain a minor revolt. WADL and WSDL 2.0 are the only attempts I am aware of to do something like this. There may be more.
  34. Re: IDL & tool support[ Go to top ]

    It doesn't answer any of the following:

    How do you structure your resource paths?
    What does the structure of the message for a given type of resource look like? (no, XML, JSON, etc. are not answers).
    Where do I find human documentation for the services?
    Who should I contact with questions or issues?
    Those questions (or their equivalents) were not answered by CORBA, DCOM or WS stack either, but that didn't hurt their popularity one bit. And no, nobody takes seriously.
    But as long as the REST community keeps putting it's hands over it's ears and yelling "LALALALALALALA!" they will remain a minor revolt.
    REST won't make it big because it's too simple for service consumers and too hard for service providers. Former cuts out tool vendors, latter is problematic because the "chicken or egg dillema" for such technologies always starts on the server side. Also, most of those that embraced REST are badly scarred by the WS-* protocol soup made by architectural astronauts, so they're not trusting extensions or additional protocols by default.
    WADL and WSDL 2.0 are the only attempts I am aware of to do something like this. There may be more.
    I welcome that those two (and similar efforts), but I wouldn't bet that they will make much headway regarding your questions. Things like that are ill-defined at the moment and turn to be hard to solve when you arrive to a meaningful definition. My personal take on them: 1) This belongs to (human-readable, machine-readable documentation is a bit of a contradiction in terms) documentation when it can't be solved by hypertext. 2) They are. More precisely, XML Schema and similar technologies are. How to get the type w/o getting the representation is probably poorly defined, but I don't know much about this part. I'd use Content-Type, but I bet there are some nasty surprises. 3) Other technologies do fine w/o putting references to that in interfaces. 4) See above. This usually comes with documentation anyway. I could also refer you to Google Data APIs, but that would be punching below the belt.
  35. Re: IDL & tool support[ Go to top ]

    It doesn't answer any of the following:

    How do you structure your resource paths?
    What does the structure of the message for a given type of resource look like? (no, XML, JSON, etc. are not answers).
    Where do I find human documentation for the services?
    Who should I contact with questions or issues?
    Those questions (or their equivalents) were not answered by CORBA, DCOM or WS stack either, but that didn't hurt their popularity one bit.
    WS* answers some of them (but not well IMO). Are you sure this isn't the reason for the failures of DCOM and CORBA? Maybe it's not. Just a thought. If REST had a better solution it might suck the last bit of life out of WS*.
    I welcome that those two (and similar efforts), but I wouldn't bet that they will make much headway regarding your questions. Things like that are ill-defined at the moment and turn to be hard to solve when you arrive to a meaningful definition.

    My personal take on them:
    1) This belongs to (human-readable, machine-readable documentation is a bit of a contradiction in terms) documentation when it can't be solved by hypertext.
    That's a valid position but I would like to hear a coherent argument about why it wouldn't be nice to do a get on a standardized relative path and get back a clean document mapping out the services I can call. As far as I can tell, this is all ad hoc. Is the argument that "it works" and nothing else?
    <2) They are. More precisely, XML Schema and similar technologies are.
    How to get the type w/o getting the representation is probably poorly defined, but I don't know much about this part. I'd use Content-Type, but I bet there are some nasty surprises.
    I'm sorry, you lost me. 'They are' what exactly?
    3) Other technologies do fine w/o putting references to that in interfaces.
    4) See above. This usually comes with documentation anyway.

    I could also refer you to Google Data APIs, but that would be punching below the belt.
    CORBA and DCOM aren't doing fine in my estimation and WS* does have an IDL. Companies like Google and Amazon are actually very poor examples because they can impose their will on others. I use to work on a B2B system that communicated with Amazon and a number of other similarly well known organizations. They make the rules. Whether what they are doing is the right thing (it's often not) doesn't matter. You play by their rules or you don't play at all. These companies can provide services and people will build businesses around helping people use those services. Small players don't have this option. I don't think that documentation for humans is going anywhere and I'm actually not interested in code generation (which is often what these descriptions are used for). And actually I think REST is quite usable without an standardized IDL. But there's an overhead to the ad-hoc approach to documenting contracts and I haven't seen any argument for it that convinces me it's necessary. So after I've posted IDL a dozen or so times, I've realized it's the wrong term to use to make my point. I'm actually in agreement with this: http://netzooid.com/blog/2008/02/07/why-a-restful-idl-is-an-oxymoron-and-what-we-really-need-instead/ In which he calls this a resource description language. I'm not sure this tells you how to get to a resource (e.g. does the doctor's id or the patient's id go first?) but that's something I think is needed, especially for things that don't map that cleanly to resources e.g. bank transfers.
  36. But until REST has a widely adopted IDL and some toll support around it, I doubt it will become a major force in the 'enterprise' space.
    IDL = RFC2616


    This is exactly the kind of attitude I am referring to. There's a Restafarian dogma that no IDL is needed.
    Hi James, WADL and WSDL doesn't help much either. To know how to use a service normally means reading the documentation, looking at examples and trying out the service yourself. REST encourages the idea of self descriptive data so what is wrong with: GET http://myservice/userguide.html Written in plain English instead of XML? The idea that a machine readable service description actually adds value is unproven IMO. The main point is that with REST a machine readable interface description is optional whilst with SOAP it is compulsory. The difference is that late-bound systems (REST) avoid fixing the interface early unlike early bound systems (SOAP). With a late bound interface, the interface is open to extension without breaking existing clients, this is not the same with SOAP. Also with late bound systems you can have soft failures. Think about broken links on the web. Some links may be broken, but the system as a whole keeps working. Late binding is a more flexible and dynamic approach. WSDL fixes the service interface at compile time, much like static typing does and hence is more brittle, and less suited to distributed applications where you don't have control over your clients. Paul.
  37. But until REST has a widely adopted IDL and some toll support around it, I doubt it will become a major force in the 'enterprise' space.
    IDL = RFC2616


    This is exactly the kind of attitude I am referring to. There's a Restafarian dogma that no IDL is needed.


    Hi James,

    WADL and WSDL doesn't help much either. To know how to use a service normally means reading the documentation, looking at examples and trying out the service yourself.

    REST encourages the idea of self descriptive data so what is wrong with:

    GET http://myservice/userguide.html
    Absolutely nothing other than how do I find out what that path is?
    Written in plain English instead of XML? The idea that a machine readable service description actually adds value is unproven IMO.
    I disagree. For example, schemas have a lot of value. They give a concise description of a document structure in a precise manner. Because it's machine readable, it can be used to generate diagrams and other things useful to developers and non-developers alike. These are not theoretical benefits. I use them on a daily basis. You could say that I am looking for a schema of the entire set of services on a domain.
    The main point is that with REST a machine readable interface description is optional whilst with SOAP it is compulsory.
    I'm not suggesting it should be required.
    The difference is that late-bound systems (REST) avoid fixing the interface early unlike early bound systems (SOAP).

    With a late bound interface, the interface is open to extension without breaking existing clients, this is not the same with SOAP.
    I don't like SOAP which is only used superficially in most modern WS* implementations. Please don't set up a straw man. I am not here to argue for SOAP. I want to help RESTful services bury it.
    Also with late bound systems you can have soft failures. Think about broken links on the web. Some links may be broken, but the system as a whole keeps working.
    That's fine as long as you have an intelligent actor navigating the links. In your average IT shop this means someone gets paged at an ungodly hour of the night. Fixed interfaces are a requirement in that environment, not a limitation. The proper way to support changes in this space is through versioning. This is something else that is needed and isn't supported well in WS* either.
    Late binding is a more flexible and dynamic approach. WSDL fixes the service interface at compile time, much like static typing does and hence is more brittle, and less suited to distributed applications where you don't have control over your clients.

    Paul.
    But the lack of control is exactly why you need static interfaces. How do you prevent your clients from using non-lenient validation on documents retrieved from the service. You can't. When you add fields, you break them. You can tell them they are stupid for doing that but that's not a solution. The reality is that there are few changes that you can make to an distributed interface that will not cause problems for the clients.
  38. Hi James, Sounds as though you've got a specific use-case in mind.
    I disagree. For example, schemas have a lot of value. They give a concise description of a document structure in a precise manner. Because it's machine readable, it can be used to generate diagrams and other things useful to developers and non-developers alike. These are not theoretical benefits. I use them on a daily basis.

    You could say that I am looking for a schema of the entire set of services on a domain
    Good. So WADL is right up your street :) This is not the same as compelling it onto the whole world though :).

    The difference is that late-bound systems (REST) avoid fixing the interface early unlike early bound systems (SOAP).

    With a late bound interface, the interface is open to extension without breaking existing clients, this is not the same with SOAP.


    I don't like SOAP which is only used superficially in most modern WS* implementations. Please don't set up a straw man. I am not here to argue for SOAP. I want to help RESTful services bury it.

    In your average IT shop this means someone gets paged at an ungodly hour of the night. Fixed interfaces are a requirement in that environment, not a limitation. The proper way to support changes in this space is through versioning.
    In the "enterprise space" where you have control over both client and server, then versioning is an option. In the public internet you do not have such control. Imagine if the whole world had to synchronise updates to all their web pages at the same time applying the same version stamp to avoid broken links. Before the web there were many attempts at an hyper-text system and they all failed precisely because of this reason, until someone came up with the idea that broken links didn't matter:)
    Late binding is a more flexible and dynamic approach. WSDL fixes the service interface at compile time, much like static typing does and hence is more brittle, and less suited to distributed applications where you don't have control over your clients.

    Paul.


    But the lack of control is exactly why you need static interfaces. How do you prevent your clients from using non-lenient validation on documents retrieved from the service. You can't. When you add fields, you break them. You can tell them they are stupid for doing that but that's not a solution. The reality is that there are few changes that you can make to an distributed interface that will not cause problems for the clients.
    You need to stand back an understand the design goals of the web. I agree that it doesn't solve all problems, but if you read Roy Fielding's paper he was concerned about mass-scale distributed applications, hence no state, an uniform connector and late-binding. This mix doesn't suite all scenarios, but it is a good fit for a global public network which isn't controlled by any single party. In his paper Roy Fielding also mentions other architectural styles. It could be argued that an alternative architectural style other then REST is better suited to enterprise scenarios where you have full control and you don't want soft failures. REST isn't a silver bullet for all distribution problems, but I think it is a good fit for the web as we know it today. Paul.
  39. This is not the same as compelling it onto the whole world though :)
    That is the opposite of what is happening. People who want to make this happen for those who need it are being drowned out by those who claim it isn't needed.
    In the "enterprise space" where you have control over both client and server
    Absolutely wrong. In my previous job we were communicating with literally hundreds of external entities. In the enterprise you are sometimes the client and sometimes the host and sometimes both. We get it from all ends.
    In the public internet you do not have such control. Imagine if the whole world had to synchronise updates to all their web pages at the same time applying the same version stamp to avoid broken links.
    I think you misunderstand. I mean you run multiple versions of the same service concurrently. You might need a dozen versions at once. You need a way to tell clients what versions are there and when old versions are becoming obsolete.
    You need to stand back an understand the design goals of the web. I agree that it doesn't solve all problems, but if you read Roy Fielding's paper he was concerned about mass-scale distributed applications, hence no state, an uniform connector and late-binding. This mix doesn't suite all scenarios, but it is a good fit for a global public network which isn't controlled by any single party
    I'm not criticizing REST. Why are you suggesting that I am? I don't see why REST can't work for the enterprise. It's just missing one piece that wouldn't affect anyone if they didn't need it. Are you saying that providing a document that describes RESTful web services would make them no longer RESTful?
  40. Hi James, A broken link (404 Error) is the webs way of telling you that it no longer wishes to provide a particular service (resource). In public life people can tell you to go away any time they like. What you decide to do is up to you. You can go bother someone else or give up gracefully. So there are no service guarantees on the web. I think this is just a reflection of public life in general. I knew of a great Greek restaurant in North London that I use to go to years ago. I decided to go back and see if they was still there only to find that it had been turned into an estate agent :) Don't get me wrong, in many scenarios such a guarantee is useful (especially if you are paying), but this is not uniformally the case and hence shouldn't be a global uniform constraint. I would suggest that you layer what additional behavior you want onto a base RESTful architecture by defining your own domain specific application protocol. I don't understand your complaint with REST as an architectural style. The alternative is the WS-* approach where you attempt to legislate for all application scenarios up front. I don't think that approach works. Explain what you have in mind. You've got me intrigued :) Paul.
  41. A broken link (404 Error) is the webs way of telling you that it no longer wishes to provide a particular service (resource). In public life people can tell you to go away any time they like. What you decide to do is up to you. You can go bother someone else or give up gracefully.
    Of course. I'm not suggesting that this would change. I used to for a middleman company. We were a vendor and a customer sometimes to the same companies. If we suddenly dropped our service that say, Apple was communicating with, it wouldn't be 'OK'. Head's might roll if it didn't get put back exactly like it was in a matter of hours. Our bosses didn't want Apple finding someone else to supply them. At the same time we would need to provide the same service with some incompatible enhancements to say Amazon. We had to do both at the same time. It wasn't up for debate. The idea would be to define a standard path for a description reference and a standard format for that document. This would be done in REST style. It would just be a resource that tells you where other resources are e.g. how to build a path to a resource and what that resource returns in detail. I'm thinking that the service version would be part of the URI. So if I finally decided that no one should be calling the old version of something and I'm ready to drop it, it would produce a 404 like you mention above.
    So there are no service guarantees on the web. I think this is just a reflection of public life in general. I knew of a great Greek restaurant in North London that I use to go to years ago. I decided to go back and see if they was still there only to find that it had been turned into an estate agent :)
    Great but there are service guarantees in business. Enterprises have service requirements with their partners and customers.
    I would suggest that you layer what additional behavior you want onto a base RESTful architecture by defining your own domain specific application protocol.
    That's what I am talking about.
    I don't understand your complaint with REST as an architectural style.
    Maybe that's because I don't have one. What I have a complaint with is RESTafarians going ape-shit whenever someone suggests it might be nice to have something standard to describe a domain's services.
    The alternative is the WS-* approach where you attempt to legislate for all application scenarios up front. I don't think that approach works.

    Explain what you have in mind. You've got me intrigued :)
    I'll try to give you something more detailed later. I thought that what I want would be obvious but maybe I'm just a fish that doesn't know anything about water in this case.
  42. Hi James, I think I understand you. The question in my mind is what should the "standard" service description be? When you start to think about it, the content of a standard description is not so obvious. I'm not sure there is such a thing as a standard service for instance, so why should there be a standard service description? Thus far everyone is assuming that such a description should be in XML. Why? REST is representation independent, so why not Postcript or HTML containing plain English like I suggested earlier? It is fine if a bunch of people want to define a common protocol above REST, but I don't think it becomes a standard until it is widely accepted and in wide spread use (defacto style). I'm much happier leaving such things to emerge over time from the user community rather then relying on standards committees to pluck them out of thin air. Personally I would rather describe my service in an HTML document with diagrams and text, then with XML, but thats just me :) I agree a few conventions in the RESTful world would be useful, but I think thats happening. Paul.
  43. Hi James,

    I think I understand you. The question in my mind is what should the "standard" service description be?

    When you start to think about it, the content of a standard description is not so obvious. I'm not sure there is such a thing as a standard service for instance, so why should there be a standard service description?
    That's a sort of "turtles all the way down" argument. Why should there be a consistent interface as described by REST? Why shouldn't everyone just do whatever they want? You've got to start somewhere. The point of this is so that you can find out what the services are and what to call them. If you can't find this document, it's not helpful.
    Thus far everyone is assuming that such a description should be in XML. Why? REST is representation independent, so why not Postcript or HTML containing plain English like I suggested earlier?
    Because it's much less useful. It's hard to say whether a text document meets the standard, first of all. It also can't be used for automation.
    It is fine if a bunch of people want to define a common protocol above REST, but I don't think it becomes a standard until it is widely accepted and in wide spread use (defacto style).
    The word standard is overloaded. There are defined standards and defacto standards. One doesn't necessarily imply the other.
    Personally I would rather describe my service in an HTML document with diagrams and text, then with XML, but thats just me
    Well, your HTML should be XHTML which is in fact XML. And any XML can be trivially transformed into HTML. XML therefore is more general and solves more problems.
  44. Hi James, I can see we will have to agree to disagree here..
    Hi James,

    I think I understand you. The question in my mind is what should the "standard" service description be?

    When you start to think about it, the content of a standard description is not so obvious. I'm not sure there is such a thing as a standard service for instance, so why should there be a standard service description?


    That's a sort of "turtles all the way down" argument. Why should there be a consistent interface as described by REST? Why shouldn't everyone just do whatever they want?

    You've got to start somewhere. The point of this is so that you can find out what the services are and what to call them. If you can't find this document, it's not helpful.
    The names of resources don't tell you how to use the service for instance. They don't describe semantics (meaning) which is the important bit for most people. The RESTful constraints as applied to the web are very clear. I am not saying "any thing goes", what I am saying is that the existing constraints are sufficient.
    Thus far everyone is assuming that such a description should be in XML. Why? REST is representation independent, so why not Postcript or HTML containing plain English like I suggested earlier?


    Because it's much less useful. It's hard to say whether a text document meets the standard, first of all. It also can't be used for automation.
    The dreaded word automation. This is my biggest fear. The main use of WSDL is to support code generation tools. I think this is why a lot of people are uncomfortable with WADL. We can do without the WS-* tools camp trying to expliot REST too :)
    Personally I would rather describe my service in an HTML document with diagrams and text, then with XML, but thats just me


    Well, your HTML should be XHTML which is in fact XML. And any XML can be trivially transformed into HTML. XML therefore is more general and solves more problems.
    This is exactly my point. Last time I checked text/html was still a valid mime type. Along with Postcript, SVG and a bunch of others. Just because XML is in vogue with some it doesn't make it the right solution for everyone After observing the WS-* circus, I think many in the REST community are suspicious of anyone trying to tell them what their higher level protocols should be. I don't think people need to be told, the beauty of REST (and the web actually) is that as long as you stick to the basic RESTful constraints you are free to do what ever suites you. Paul.
  45. Hi James,

    I can see we will have to agree to disagree here..

    Hi James,

    I think I understand you. The question in my mind is what should the "standard" service description be?

    When you start to think about it, the content of a standard description is not so obvious. I'm not sure there is such a thing as a standard service for instance, so why should there be a standard service description?


    That's a sort of "turtles all the way down" argument. Why should there be a consistent interface as described by REST? Why shouldn't everyone just do whatever they want?

    You've got to start somewhere. The point of this is so that you can find out what the services are and what to call them. If you can't find this document, it's not helpful.


    The names of resources don't tell you how to use the service for instance. They don't describe semantics (meaning) which is the important bit for most people. The RESTful constraints as applied to the web are very clear. I am not saying "any thing goes", what I am saying is that the existing constraints are sufficient.
    I am proposing a document that would describe the semantics. I don't understand your point at all.
    The dreaded word automation. This is my biggest fear. The main use of WSDL is to support code generation tools. I think this is why a lot of people are uncomfortable with WADL. We can do without the WS-* tools camp trying to expliot REST too :)
    Automation != Code generation. code generation is the most rudimentary form of automation IMO. I am also not in favor of code generation but I think this argument is a bit like cutting off your nose to spite your face. You can't prevent people from being dumb. You can only show them better ways.
    Last time I checked text/html was still a valid mime type. Along with Postcript, SVG and a bunch of others.
    I seriously don't get why this argument is used so frequently. Just because you can specify the type of a document doesn't mean you've explained what the internal structure is. I can look at a file with an csv extension and I know how what format specification is uses but that doesn't tell me what data entities the columns represent. This really seems like a silly argument to me. I wish someone would explain how knowing the type of the content is enough.
    Just because XML is in vogue with some it doesn't make it the right solution for everyone

    After observing the WS-* circus, I think many in the REST community are suspicious of anyone trying to tell them what their higher level protocols should be.
    It doesn't have to be XML. It could be JSON or some other structured format. And there's no reason it couldn't be published in multiple formats. XML is just the most commonly understood. And I'm not telling anyone what to do. I'm saying what I would need to be able to use REST in my organization. I've already tried sneaking it in and that didn't work.
    I don't think people need to be told, the beauty of REST (and the web actually) is that as long as you stick to the basic RESTful constraints you are free to do what ever suites you.
    The beauty of a car is that I can drive it anywhere there are roads. The downside is that I can also just as easily drive it into a ditch at high-speed. Consider what would happen if airplanes worked with the REST model. No flight plans, no air traffic controllers. Just planes flying around wherever they pleased. Would you travel by plane under such a system or for that matter live anywhere near an airport?
  46. REST encourages the idea of self descriptive data so what is wrong with:

    GET http://myservice/userguide.html

    Written in plain English instead of XML? The idea that a machine readable service description actually adds value is unproven IMO.

    The main point is that with REST a machine readable interface description is optional whilst with SOAP it is compulsory.
    I agree Paul. It's nice to see someone is questioning the validity and complexity of SOAP on this thread instead of the REST backlash I see going on. The notion that RESTful web services are not static, lack type safety, are too dynamic, etc. is FUD in my humble opinion. People who make this argument seem to lack imagination. If the clients and service are both written in Java, type-safety in REST can easily be achieved. What is preventing you from designing a type-safe client interface for your RESTful web service and distributing it? Using standard Java features such as generics and serialization you can easily build a RESTful web service that supports versioned entities/resources. Simply distribute your model classes (DTO objects) with the client library and the client can pass these to your web service over HTTP using serialization. This would enable you to support different versions of your model as your service evolves. If the clients are not written in Java, you can still use XML, JSON, or any other representation supported by your implementation. You could use separate URI spaces for the different versions of your service (e.g. /service/1.1/foo, /service/1.2/foo, and so on). Ian
  47. I agree Paul. It's nice to see someone is questioning the validity and complexity of SOAP on this thread instead of the REST backlash I see going on.
    You actually agree with me. You in fact are on the other side of me from Paul on this. Or that's the way it looks from the rest of your post, anyway.
  48. I agree Paul. It's nice to see someone is questioning the validity and complexity of SOAP on this thread instead of the REST backlash I see going on.


    You actually agree with me. You in fact are on the other side of me from Paul on this. Or that's the way it looks from the rest of your post, anyway.
    Hi James, I totally agree with Ian. What he advocates is exactly what I have been suggesting you do. I concluded that you weren't listening and this response confirms it. The REST constraints are sufficient for loosely coupled mass scale distributed web applications. If you want anything else in addition (service description, interface versioning etc), then you can layer this stuff on top of REST yourself. We are old friends James and I know you are intelligent and thoughtful. Read Roy Fieldings dissertation. You have said some things above that are just plain wrong. You can have all you want with REST, no one can stop you. The difference with WS-* is that there is no one pushing layers of application protocols which are over-complex and may not meet your specific needs, instead you are free to think through your own application protocol to meet your own needs. If others have the same needs ( service description, versioning etc), then hopefully a convention will arise where people choose to solve the same problem in a similar/same way. No need to dis REST, you are in full control (including not using REST if you so choose). Paul.
  49. I agree Paul. It's nice to see someone is questioning the validity and complexity of SOAP on this thread instead of the REST backlash I see going on.


    You actually agree with me. You in fact are on the other side of me from Paul on this. Or that's the way it looks from the rest of your post, anyway.

    Hi James,

    I totally agree with Ian. What he advocates is exactly what I have been suggesting you do.
    You're advocating static typing now? When did you have the change of heart? Ian just described exactly what I have been saying needs to be done on top of REST. What is it about the way I am explaining this that makes it confusing? I don't have any idea what you (and apparently others) think I am advocating. I don't want to change REST at all.
    I concluded that you weren't listening and this response confirms it.
    But what he said was what I have been suggesting the whole time. Who isn't listening?
    The REST constraints are sufficient for loosely coupled mass scale distributed web applications. If you want anything else in addition (service description, interface versioning etc), then you can layer this stuff on top of REST yourself.
    This is what I have been saying the whole time. The thing is that I can't do this by myself. It doesn't help. You still seem to be under the impression that enterprises don't communicate with external entities. If every organization comes up with their own way of doing this it won't provide much benefit.
    You have said some things above that are just plain wrong.
    Such as?
    No need to dis REST, you are in full control (including not using REST if you so choose).
    I'm advocating REST. Why does my desire for specification based on REST mean I am 'dissing' REST? I hate SOAP and WS*. What do I need to say to make this clear?
  50. Hi James, I won't attempt to answer all your points, but I will respond to some :)
    I'm advocating REST. Why does my desire for specification based on REST mean I am 'dissing' REST? I hate SOAP and WS*. What do I need to say to make this clear?
    Well when you bodly state:
    I think the focus of the potential malleability of REST style services is a disservice to the REST approach. Services that change or disappear at any time without warning only seem like a good idea to the uninitiated. No real world web service can just change without warning and not cause havoc. In fact, services are often set in stone. The only way to change them is to create a new version and clients migrate. The real value of REST is, IMO, the much simplified approach over WS*. But until REST has a widely adopted IDL and some toll support around it, I doubt it will become a major force in the 'enterprise' space.
    You better be prepared to back it up :) As for the stuff that is plan wrong, Fieldings dissertation does not specify what operations a uniform connector should support, it merely says that the connecter should be uniform with a fixed set of operations (verbs). HTTP is just one example of a uniform connector. You can do REST without HTTP (in fact I believe Fielding came up with an alternative uniform connector that he believes is better then HTTP). I am not advocating early binding or tight coupling, but I am willing to accept that some people may want to do this. (A bit like an XML service description, I don't know why you would want to do it, but hey I am willing to accept freedom of choice :)) With loose coupling and late binding built into your resource request resolution mechanism, you can add tighter coupling and early binding (WSDL, WADL or whatever) on top if you wish. WS-* takes the RPC aproach where tight coupling and early binding is built into the transport. So you loose the option for late-binding. Now you are not making much sense, and you can't blame the rest of us for being confused :) Either describe the problem you are trying to solve and your specific solution that adheres to the REST constraints as described in Fielding's dissertation or pipe down. I asked you what you had in mind a long time ago, and other then handwaving and a general uncivil and defensive diatribe, you have yet to state anything concrete and specific. So Again: What do you have in mind specifically? PS. Why do you need a spec? If you and your partner companies agree an application protocol based on REST why isn't that sufficient? That is the whole point about something being optional, you opt-in. Any spec that is not compulsory (like WS-*) is no different from an application specific protocol shared by a self selecting group. You have no guarantee that clients or servers outside this group will adhere to the spec, precisely because its optional. So you really need to think through what you are saying. Are you advocating a WS-* approach where you dictate compulsory application protocols for everyone or are you leaving it down to consenting parties to agree application specific protocols between themselves? Its has got to be one or the other. If it is the first then it is not REST by definition, since REST doesn't fix the representation which is left as application specific. REST says nothing about what resources should be available on a valid server either and it also doesn't specify the structure of resources other then suggesting that they should be self describing (e.g. hyper-links). This is all left to the application. The Web adheres to these RESTful principles and is hugely successful. Think about it :) Paul.
  51. Hi James, While we are waiting for your RESTful IDL, I thought I'd post a link to a blog post that makes the same point I'm making (only much better): http://bitworking.org/news/193/Do-we-need-WADL The only question left in my mind is whether you can make up your own mime-types in HTTP. The mime-type doesn't only tell you the representation, it defines the application protocol too. If you recognise the mime-type you are part of the application, if you don't then your are outside the self selecting group :) No different then getting an SVG resource with a browser (client) that doesn't support the SVG mime-type: 'image/svg+xml'. The generic XML mime type is 'application/xml', which sorts of implies that there is this generic XML application out there that everyone understands, which is obviously not true. I much prefer 'application/opensearch-xml' as the mime type for the Open Search application which uses an xml representation. If you've implemented your client to the Open Search spec then you don't need a service description from the server. The service description is implicit in the mime-type. BTW this is another point you made earlier (mime-types only specify the representation) which is plain wrong. Paul.
  52. You better be prepared to back it up :)
    Which part? That services dissapearring or changing without warning is not acceptable in a large number of situations or that REST is a much simpler (or sounder) basis for web services than SOAP/WS*?
    As for the stuff that is plan wrong, Fieldings dissertation does not specify what operations a uniform connector should support, it merely says that the connecter should be uniform with a fixed set of operations (verbs).
    I already addressed this in this thread and admitted that it was incorrect as stated. What I meant is that RESTful web services (in general) use standard verbs and that it is argued that the four common ones are all you need to support web services. Do you disagree?
    WS-* takes the RPC aproach where tight coupling and early binding is built into the transport. So you loose the option for late-binding.
    I never said the specification of the web services must be static. You like SmallTalk, right? Correct me if I'm wrong but in SmallTalk, reflection is a big part of the language. You can ask an object, "what operations do you have?" This doesn't cause you to lose the option of late binding. It enhances what you can do with late binding. What would be so bad about having a similar approach to web services based on REST?
    Now you are not making much sense, and you can't blame the rest of us for being confused :)
    When did I blame anyone? Sometimes when a question is asked, it's a real, sincere question.
    Either describe the problem you are trying to solve and your specific solution that adheres to the REST constraints as described in Fielding's dissertation or pipe down.

    I asked you what you had in mind a long time ago, and other then handwaving and a general uncivil and defensive diatribe, you have yet to state anything concrete and specific.
    How am I being uncivil and defensive exactly? What have I written that even compares to the rudeness of this paragraph? You say I'm a friend but you sure aren't treating my like one. Why can't we discuss this rationally? We are just working though some misunderstandings? What's with the acrimony? I've told you what I am looking for a number of times. A specification for a document that defines the types of resources available on a domain, how to resolve them and what inputs they allow/require and what outputs they produce. The other thing on my wish list is a standard location/name for this document so that given a domain like foobar.com, I can do a GET on e.g. foobar.com/spec and if the domain supports this hypothetical standard, I will get back this document.
    So Again: What do you have in mind specifically?
    Personally, I think the above is pretty specific. If you don't know what it means, just say so but please stop accusing me of not saying what I want.
    PS. Why do you need a spec? If you and your partner companies agree an application protocol based on REST why isn't that sufficient?
    Why do we need DNS? Let's say my company has 500 partners. Those companies each have hundreds of partners. What do you think the odds are that will all agree on the same homegrown protocol? What ends up happening is that each company has to support many different protocols to accomplish the same things. if you accept that this is the reality of the situation, the value of not having to hunt down and keep track of hundreds of ad hoc approaches to documentation and specification should be apparent.
    So you really need to think through what you are saying.
    I've thought it through.
    Any spec that is not compulsory (like WS-*) is no different from an application specific protocol shared by a self selecting group. You have no guarantee that clients or servers outside this group will adhere to the spec, precisely because its optional.
    I'm sorry, you refer to WS* as not compulsory and then as compulsory. Either one is a typo or I'm not following your logic. All specs are optional unless someone, say the government is forcing you to support them (which is actually a real issue where I work.) When two companies agree to use SOAP-based Web Serivces or WS*, they are deciding to do so. There's no guarantee that any given entity will support WS*. So I'm not really sure what it is that you are saying here.
    If it is the first then it is not REST by definition, since REST doesn't fix the representation which is left as application specific. REST says nothing about what resources should be available on a valid server either and it also doesn't specify the structure of resources other then suggesting that they should be self describing (e.g. hyper-links).
    Does REST forbid resources from having a specification or for domain from having a directory?
    This is all left to the application.
    So if two organizations agree to use a standardized or structured approach to their application protocol it's not REST? Is that what you are saying or not?
  53. Hi James, Are you purposely misunderstanding what I am saying? WS-* compels you to use XML, create a WSDL etc, REST does not... You no what... like others before. I give up:) If you stop the arm waving and actually try and work out the details of what you are suggesting then you will realise that you are suggesting yet another WADL. Without the detail all you have said is just hot air. Paul.
  54. Let me clear up the "typo" so there is no cofusion:
    PS. Why do you need a spec? If you and your partner companies agree an application protocol based on REST why isn't that sufficient? That is the whole point about something being optional, you opt-in. Any spec that is not compulsory (unlike WS-*) is no different from an application specific protocol shared by a self selecting group. You have no guarantee that clients or servers outside this group will adhere to the spec, precisely because its optional.
    You no what, I shouldn't bite :) But your bold assertions have got me peeved :) Please Please show us your IDL (who knows, you may have made a major break through in computer based ontology :)). Paul.
  55. You no what, I shouldn't bite :) But your bold assertions have got me peeved :)

    Please Please show us your IDL (who knows, you may have made a major break through in computer based ontology :)).

    Paul.
    I really wish I had tried to make my points in a way that wasn't irksome to you. I say 'tried' because I haven't succeeded. It is not my intention to make anyone angry or to tear down REST. It's quite the opposite, actually. I think REST is the foundation for the future of web services. As for my bold assertions. I don't think I've asserted anything that isn't trivial. If you have specific issues with things I've said, please point them out on a case-by-case basis as you have begun to do. You've already pointed out two things that I have been wrong about. The most helpful being the point about using more specific mime types that specify structure. I want to talk more about this but I'm unable to give it adequate time at this moment. But the point is, I may be arrogant but I am not stupid. If you show me to be wrong, I'll readily absorb that new knowledge. I really perplexed that my posts are so irritating to you. I think you are misinterpreting my intentions and possibly the lack of visual or audible cues combined with cultural differences and my inability to explain things the way a normal person would are causing you to take my posts as defensive or aggressive. I'm really looking to build consensus and failing miserably. I'm honestly pretty bummed out about it.
  56. One more thing. I really wish you would address the questions I have asked. Specifically, can you respond to at least these two? I just want to make sure I understand your position. Does REST forbid resources from having a specification or for domain from having a directory? So if two organizations agree to use a standardized or structured approach to their application protocol it's not REST? Is that what you are saying or not?
  57. One more thing. I really wish you would address the questions I have asked. Specifically, can you respond to at least these two? I just want to make sure I understand your position.

    Does REST forbid resources from having a specification or for domain from having a directory?

    So if two organizations agree to use a standardized or structured approach to their application protocol it's not REST? Is that what you are saying or not?
    Hi James, I wasn't so much anoyed, more frustrated actually. Firstly I would suggest that you suspend any prior context that you bring to this discussion, REST does things differently. In answer to your specific questions: Application protocols are defined by media type (what I've been calling mime type up until now). Think of protocols as layers. Network protocols sit at the bottom and are concerned with moving data safely from one adress to another. Application protocols sit above this and are a way for remote parts of the same application to talk to each other. A distributed application consists of parts that are geographically dispersed. A web browser and a web server working to deliver HTML pages is just one example of a distributed application (media type 'text/html'). So application protocols tend to be application specific. So as pointed out in the last link I supplied: http://bitworking.org/news/193/Do-we-need-WADL You can specify a media type as an indicator of the application protocol being used. There are several types of application on the web. This wikipedia link list them all: http://en.wikipedia.org/wiki/Mime_type Something I've just found out is that you can use your own media type by prefixing it with an x. So: application/x-myapp-xml Is my own application specific protocol. Now you can try and get this accepted as a RFC standard if you wish. The idea as I understand it is to introduce as few new application protocols to the web as possible. So people are repurposing existing application protocols in new and interesting ways. Apparently Google as done a lot of this with the Atom protocol. Here is a link to a site that talks about this stuff: http://simplewebservices.org/index.php?title=Main_Page The shopping example on this site is an attempt to come up with a protocol suited to e-commerce. On the original blog I linked to is a daytrader RESTFul application that I found very useful as a learning tool: http://bitworking.org/news/201/RESTify-DayTrader So people are working on "conventions" and consistent approaches. As for protocol specifications, well these are application/domain specifc. So yes REST does allow for these. As part of your protocol you could implement a directory service, so yes REST allows for this too. The difference is that REST doesn't try to pretend that there is this global generic application protocol like application/xml and WSDL that everyone should adhere to. I hope that helps. BTW I'm no expert, but I believe what I've said here is acurate. Paul.
  58. Firstly I would suggest that you suspend any prior context that you bring to this discussion, REST does things differently.
    I can try but if I can't ask how REST addresses my requirements, how can I determine if REST addresses my requirement? What has been discussed and what I have read in other places including the link you give below about WADL do not address my requirements. If there is a way that RESTful web services already address my requirements, that's great. I just don't see how they do.
    You can specify a media type as an indicator of the application protocol being used.

    There are several types of application on the web.
    That makes a lot of sense for general protocols like Atom. But for things like purchase orders or invoices, I just don't think it will be feasible. I used to work with a set of protocols for this kind of thing. They had maybe 100 different types of documents with many different versions. In order to fit so many different needs, they were extremely generic; so much so that we had to write up custom documentation of what the fields inside this spec meant in the context of each trading partner. On top of that, we ended up having to customize it for each organization because as general as it was, it still didn't address things that we needed to do. Honestly, I'm not sure that a lot of these things deserve to be RFC standards. They are just too specific to a domain or organization.
    Something I've just found out is that you can use your own media type by prefixing it with an x. So:

    application/x-myapp-xml

    Is my own application specific protocol. Now you can try and get this accepted as a RFC standard if you wish.
    This was a question that I wanted to ask i.e. whether we could just make up our own names. So the answer is yes. But if I create my own name, where does the user of the service go to find the documentation of this custom protocol. As far as I know, HTTP doesn't provide any way of pointing to where the specification for this custom media type can be found. Is that correct?
    As for protocol specifications, well these are application/domain specifc. So yes REST does allow for these. As part of your protocol you could implement a directory service, so yes REST allows for this too.
    So most basic part of what I would like to have is a directory of the services that are defined. It seems to me that this could be totally optional. We could create a directory document and apply it to existing RESTful services. If a domain doesn't provide the directory, you would just get a 404 when you asked for it. No one would be forced to use this directory. Does this seem reasonable so far?
    The difference is that REST doesn't try to pretend that there is this global generic application protocol like application/xml and WSDL that everyone should adhere to.
    I understand that and I'm not suggesting that there should be one. What I looking for is something that tells me what a specific domain does support. If nothing I've said so far in this post creates a tussle, my next question is related to how I know what questions to ask. We've established that HTTP can tell you what types of media a given service provides. My understanding is that you would need to know what the service path is before you can ask for this information. Is that correct?
  59. If nothing I've said so far in this post creates a tussle, my next question is related to how I know what questions to ask.

    We've established that HTTP can tell you what types of media a given service provides. My understanding is that you would need to know what the service path is before you can ask for this information. Is that correct?
    Hi James, I'm glad to see some of your questions are getting answered. Before I respond to your question about service paths, I wanted to share something with you that may help. The following is from "RESTful Web Services" by Leonard Richardson and Sam Ruby (ISBN 0-596-52926-0). In Chapter 10, titled "The Resource-Oriented Architecture Versus Big Web Services", they write:
    WSDL serves two main purposes in real web services. It describes which interface (which RPC-style functions) the service exposes. It also describes the representation formats: the schemas for the XML documents the service accepts and sends. In resource-oriented services, these functions are often unnecessary or can be handled with much simpler standards. From a RESTful perspective, the biggest problem with WSDL is what kind of interface it's good at describing. WSDL encourages service designers to group many custom operations into a single "endpoint' that doesn't respond to any uniform interface. Since all this functionality is accessible through overloaded POST on a single endpoint URI, the resulting service isn't addressible. WADL is an alternative service description language that's more in line with the Web. Rather than describing RPC-style function calls, it describes resources that respond to HTTP's uniform interface. (308)
    What is alluded to here is one of the inherent problems of SOAP-based web services: the limited use of HTTP. By reducing clients to one HTTP method (POST) and one service endpoint (URI), it's easy to see why more web services infrastructure such as SOAP, WSDL, tools, etc. is needed to compensate for what is not being used efficiently, i.e. the HTTP protocol itself. With this in mind, I think you are on the right track by asking "which questions to ask". It sounds like you have significant experience with Big Web Services, so maybe you are looking for analogous constructs or mechanisms in REST. The problem is REST is based on a different paradigm than SOAP (resources vs. service interfaces), so you may not find these analogues. By the same token, because REST encourages a simpler approach when compared to SOAP, the same issues may not exist in REST and may not require the same mechanisms. The above citation touches on two key points: simplicity and addressability. I've already mentioned simplicity, but much more can be said on this topic, e.g. REST uses one envelope instead of two (HTTP vs. SOAP over HTTP). Regarding service directories (e.g. UDDI), I'm not convinced UDDI has been successful in the SOAP world, therefore why would you want to see something similar implemented in REST? As for addressability, I think this might answer your question about service paths. A RESTful web service is based on HTTP constructs such as URIs so a resource can provide explicit information linking it to other resources. This information can be presented as HTTP URLs within XML, for instance, so you could traverse the resources of a RESTful web service using XPath. Once again the point is that REST adopts a simpler approach to web services than SOAP/RPC so you may not find the same constructs in both approaches. This does not mean REST is deficient, only that it attempts to solve problems in a much simpler way. I would encourage you to read the book I mentioned above. It offers an excellent introduction to RESTful web services. Also, you will find some excellent Java frameworks and libraries for building RESTful web services out there, such as Jakarta Commons HTTP Client and Jersey (JAX-RS reference implementation). Hope it helps, Ian
  60. What is alluded to here is one of the inherent problems of SOAP-based web services: the limited use of HTTP. By reducing clients to one HTTP method (POST) and one service endpoint (URI), it's easy to see why more web services infrastructure such as SOAP, WSDL, tools, etc. is needed to compensate for what is not being used efficiently, i.e. the HTTP protocol itself.
    Please don't assume that I don't understand the difference between RESTful and SOAP-based services. You aren't telling me anything I don't already know.
    With this in mind, I think you are on the right track by asking "which questions to ask".
    I think you misunderstood what I meant by that.
    It sounds like you have significant experience with Big Web Services, so maybe you are looking for analogous constructs or mechanisms in REST.
    I would say that you are making the assumption that my questions are related to the capabilities of "Big Web Services". You should stop framing my statements in that context if you want to have a meaningful conversation.
    The problem is REST is based on a different paradigm than SOAP (resources vs. service interfaces), so you may not find these analogues. By the same token, because REST encourages a simpler approach when compared to SOAP, the same issues may not exist in REST and may not require the same mechanisms.
    I don't want to be rude, but this is analogous to explaining arithmetic when I am asking about algebra.
    The above citation touches on two key points: simplicity and addressability. I've already mentioned simplicity, but much more can be said on this topic, e.g. REST uses one envelope instead of two (HTTP vs. SOAP over HTTP).
    Again, I know all of this.
    Regarding service directories (e.g. UDDI), I'm not convinced UDDI has been successful in the SOAP world, therefore why would you want to see something similar implemented in REST?
    I never mentioned UDDI nor do I care about UDDI. Just because I say directory and one of the Ds in UDDI stands for directory doesn't mean I am talking about UDDI.
    As for addressability, I think this might answer your question about service paths. A RESTful web service is based on HTTP constructs such as URIs so a resource can provide explicit information linking it to other resources.
    I already understand this. My understanding of RESTful Web services is that these URIs are generated based on some sort of path structure, a formula if you will. One of the questions I have is where that formula is documented. The only answer I have ever gotten is that it's done in an ad-hoc fashion.
    It offers an excellent introduction to RESTful web services.
    It seems that you are assuming I am ignorant simply because you don't understand what I am saying.
  61. It seems that you are assuming I am ignorant simply because you don't understand what I am saying.
    Hi James, I don't want to be drawn into a "dissect and dismiss" type conversation with you as I've seen on this thread, so please take my comments at face value for what they were, a genuine attempt to help by sharing information with you. It seems that confusion and misunderstanding are two of the predominant themes in this thread so perhaps a broader communication problem exists that should be addressed before any "meaningful conversation" can take place. Once again, I do not assume you are ignorant, I am simply trying to help. Sorry if my posts could not be of further use to you. Ian
  62. I don't want to be drawn into a "dissect and dismiss" type conversation with you as I've seen on this thread, so please take my comments at face value for what they were, a genuine attempt to help by sharing information with you.
    I never doubted that your intent was sincere. It's kind of like when I was once out with a group of people and this guy starts telling me about how cork comes from Portugal. I'm sure he meant no harm but: 1. I already know this so it's boring. 2. It's a little insulting. The fact that it's sincere is not helping. I read or heard this somewhere recently that in respectful communication you must assume that the person you are talking to is correct and work back from there to resolve why you disagree. Assuming that the person you are communicating is wrong is unlikely to lead to a common understanding. I know I blasted Subbu earlier and probably a little too harshly but I thought it was very disrespectful to call the article 'incorrect and misleading' with such a flimsy argument. Also, I think that guy does this kinds of thing on a regular basis. I still regret my tone in any event.
  63. Hi James, I think your main question is how do I know the protocol? The simple answer is you need to find out. The idea that your application can discover new services on the web and miraculously understand the protocol and become part of a distributed application that the original programmers didn't envision is a pipe dream IMO :) WSDL and WS-* is premised on this dream. I just don't buy it :) The REST people are more pragmatic. If you are going to code to a given protocol/API then the least of your problems is finding out the URI where the service is hosted. From there REST relies on self describing data. Just like the web, were index.html is the front door to a web site once you know the URL, the same with REST, you follow the links to where you want to go from the root URI. The mime-type is another clue. If you know the mime-type, then you can lookup the associated spec and hence know where to find what you are looking for relative to the front door. I just can't see how you could code a client without reading and knowing the application protocol. This is why I said my preferred "service description" is a human readable document. Again this can be linked to from the "home page". So the important service description to me is the one that targets programmers, not machine readable XML. Machines are pretty dumb and can't do much with a description, whilst programmers can do an awful lot :) I agree you don't want a proliferation of media types. I've read somewhere that all/most? of the google applications (word processor, e-mail etc) can be accessed using a RESTful API built on Atom. Atom is a publishing protocol so can be repurposed in scenarios where a client wants to receive updates from the server. The Shopping application I mentioned before is using RDF, so repurposing seems to be the vogue. Just hazarding a guess, your service directory requirement could probably be met by repurposing an existing media type, but I couldn't tell you which one :) For me the biggest problem with REST is that it has an embarrassment of riches. There are several ways to achieve the same thing, all of which can be considered "RESTful" to a greater or lesser degree. What I think is happening is that a number of stereotypical RESTful applications are being built around a small set of mime-types, each of which can be extended (Atom for example can be extended). These "stereotypes" can serve as templates for the rest of us who can adopt the same conventions in our own applications. Now I think there will always be a cultural element to all of this. REST is not prescriptive and requires that you understand the principles and tailor any solution to your own specific problem. Now some people prefer there solutions to come shrink wrapped, nicely fitting in with the familiar programming model. For these people I agree that REST will probably be unappealing :) which is fine. Paul.
  64. Hi James,

    I think your main question is how do I know the protocol? The simple answer is you need to find out. The idea that your application can discover new services on the web and miraculously understand the protocol and become part of a distributed application that the original programmers didn't envision is a pipe dream IMO :)
    I agree and this is a strawman.
    WSDL and WS-* is premised on this dream. I just don't buy it :)
    Not really. I've only heard of this concept recently and it's always been from people dismissing the value WADL or similar ideas. No one thinks that you can do this. Well, maybe some non-technical people roped in by salespeople. What most people do is generate code and fill in the details. But let me be clear about this: I think that code generation is very overrated.
    Just like the web, were index.html is the front door to a web site once you know the URL, the same with REST, you follow the links to where you want to go from the root URI
    This is exactly what I am getting at. If index.html is a good thing for web pages, why is something similar a bad thing for web serivces? You say to follow the path but I don't think that's possible in general. For example, I might have a path like: http://foo.com/resturaunts/[country]/[province, state, etc.]/[city]/[area?] How does the web service client know how to build this path? If there's already an answer for this in standard HTTP, please tell me what it is.
    just can't see how you could code a client without reading and knowing the application protocol.
    I think part of the reason that we are having a hard time getting anywhere is that you are assuming this is what I want. It's not.
    This is why I said my preferred "service description" is a human readable document. Again this can be linked to from the "home page".

    So the important service description to me is the one that targets programmers, not machine readable XML. Machines are pretty dumb and can't do much with a description, whilst programmers can do an awful lot :)
    This argument has a somewhat Luddite feel to it. Just because programmers can deal with ad-hoc documentation doesn't mean it's the best approach. That doesn't mean it's a good idea. We don't need the atom publishing protocol. Why is that a good thing and something like what I am suggesting bad? I've said from the beginning that human readable documentation isn't going anywhere. Even if none of the documentation in this hypothetical service description document were machine readable, the mere fact that it is in an expected place (like index.html) and in a consistent form creates efficiencies. But if it was something like atom (maybe it could be based on atom?) applications could be built to create a comprehensive view of a domain. I could see all the kinds of services available and all the versions and all the supported document types and structures and plug them into my transformation tool as targets or sources in a way where I would be freed from a number of mundane tasks like associating path generation algorithms and transformations and base URIs. I could be alerts when new services or versions are added and when older ones are being deprecated. It seems to me that a lot of good things could come of this. I just don't understand the resistance to it. I'm not really suggesting anything radical. These are things that are done today in many different contexts. What's the harm in this idea? It seems like this is considered a heresy.
  65. Hi James,
    This is exactly what I am getting at. If index.html is a good thing for web pages, why is something similar a bad thing for web serivces?
    Something similar is fine, but WADL is not similar :) If you think it is then I fear you mis-understand what REST means by "self describing".
    No one thinks that you can do this. Well, maybe some non-technical people roped in by salespeople. What most people do is generate code and fill in the details. But let me be clear about this: I think that code generation is very overrated.
    Really? Well I guess you haven't read this: http://www.w3.org/TR/ws-arch/
    It seems to me that a lot of good things could come of this. I just don't understand the resistance to it. I'm not really suggesting anything radical. These are things that are done today in many different contexts. What's the harm in this idea? It seems like this is considered a heresy.
    No, not heresy, just different. REST takes a fundamentally different approach rooted in the existing web architecture. The WS-* approach with its WSDL idea advocates a new "web services" architecture that requires a service description, leading to service discovery, choreography, business process scripting, etc. See the full list: http://en.wikipedia.org/wiki/List_of_Web_service_specifications It appears to me that you aren't fully versed with either REST or WS-*, or maybe you are. Either way you are free to follow either architectural approach or to invent an architecture of your own if you so wish. Paul.
  66. Hi James,

    This is exactly what I am getting at. If index.html is a good thing for web pages, why is something similar a bad thing for web serivces?


    Something similar is fine, but WADL is not similar :) If you think it is then I fear you mis-understand what REST means by "self describing".
    I haven't really said whether I think WADL is good or not. I'm withholding judgement until I am satisfied I understand both sides of the story. I've also not taken the time to really understand WADL and what problems it solves or doesn't solve. It might be helpful if you explained why WADL is not self-describing in the REST sense. Maybe that would explain WADL is not getting traction.
    Either way you are free to follow either architectural approach or to invent an architecture of your own if you so wish.
    If index.html is REST, why would something similar to that be inconsistent with REST? What exactly makes this idea incompatible with REST. I'm not seeing how you come to this conclusion. I have to assume that because you did not respond to my question above about paths, there is no built in solution for this in HTTP or at least that you are not aware of one. Is that correct?
  67. It might be helpful if you explained why WADL is not self-describing in the REST sense. Maybe that would explain WADL is not getting traction.
    There is a good interview titled "Do we need WADL?" that explores some of the issues around WADL. That may shed more light on the subject. One of the main issues seems to be the brittleness of a service description. From my point of view, I would ask, why do I need a REST service description in the first place? I would also ask, which representations (mime types) does the service expose, and which verbs can I use? It should be specified in the web service's documentation, but I can also try sending a GET or OPTIONS to the root URI of the service. Once I have this information, I can start using the service.
    I have to assume that because you did not respond to my question above about paths, there is no built in solution for this in HTTP or at least that you are not aware of one. Is that correct?
    Paul refers to the concept of self-descriptive messages in REST. I understand this to mean that HTTP responses from the web service will contain enough information to help my client construct a valid HTTP request. Response messages consist of headers and a body containing URIs, accepted mime types, authentication/authorization details, response codes, and so on. Between the wealth of information in the HTTP envelope itself and the web service documentation, is this really insufficient for your client to use the service?
  68. It might be helpful if you explained why WADL is not self-describing in the REST sense. Maybe that would explain WADL is not getting traction.

    There is a good interview titled "Do we need WADL?" that explores some of the issues around WADL.
    I've already read it.
    From my point of view, I would ask, why do I need a REST service description in the first place? I would also ask, which representations (mime types) does the service expose, and which verbs can I use?

    It should be specified in the web service's documentation, but I can also try sending a GET or OPTIONS to the root URI of the service. Once I have this information, I can start using the service.
    I'll ask you the same question I asked Paul. It's very specific. Assume I have service with paths as follows: http://foo.com/resturaunts/[country]/[province, state, etc.]/[city]/[area?] example: http://foo.com/resturaunts/USA/CA/San+Francisco/Union+Square How does the web service client find out how to build this path? Is there anything other than ad-hoc approaches to defining this?
  69. I'll ask you the same question I asked Paul. It's very specific.

    Assume I have service with paths as follows:

    http://foo.com/resturaunts/[country]/[province, state, etc.]/[city]/[area?]

    example:

    http://foo.com/resturaunts/USA/CA/San+Francisco/Union+Square

    How does the web service client find out how to build this path? Is there anything other than ad-hoc approaches to defining this?
    Hi James, Both Ian and I have answered this one several times. Perhaps the answer is too simple. Firstly the "thing" that needs to know isn't the client agent (the software), but the client programmer (a human being). He/she can find out the application protocol a number of ways. First the simplest: 1. GET http://foo.com/ Interesting. This resource contains a URI to resturants, lets take a look... 2. GET http://foo.com/resturants/ OK this resource contains a list of country URIs. I'm interested in restaurants in Union Square San Francisco, so lets follow the link to the USA... 3. GET http://foo.com/resturants/USA I'm sure you get the idea. Another approach is to look at the mime type to see if it is a protocol I recognise then I know what to and were to look. For example Atom supports introspection and provides a "service description" at a "well known" location in a "well known" format. You seem to have a mental block here. I guess the answers are just to simple :) Paul.
  70. Hi James, I found the link to the google API's I mentioned based on APP (Atom Publishing Protocol). As you can see you can do quite a lot with APP. http://code.google.com/apis/gdata/basics.html If there isn't something amongst this lot that meets your requirements then I'd be surprised. BTW Google provides a service description for all these services APIs. Follow the links from the above page. The format they've choosen is plain English :) Paul.
  71. Hi James,

    I found the link to the google API's I mentioned based on APP (Atom Publishing Protocol). As you can see you can do quite a lot with APP.

    http://code.google.com/apis/gdata/basics.html

    If there isn't something amongst this lot that meets your requirements then I'd be surprised.

    BTW Google provides a service description for all these services APIs. Follow the links from the above page. The format they've choosen is plain English :)

    Paul.
    APP may very well meet my requirements but I don't see anything on that page that would. Of course if APP does implement what I am talking about, you would have to criticize it as non-REST since you keep claiming it's not RESTful to do this sort of thing.
  72. First the simplest:

    1. GET http://foo.com/

    Interesting. This resource contains a URI to resturants, lets take a look...

    2. GET http://foo.com/resturants/

    OK this resource contains a list of country URIs. I'm interested in restaurants in Union Square San Francisco, so lets follow the link to the USA...

    3. GET http://foo.com/resturants/USA


    I'm sure you get the idea.
    That's ad-hoc. So the answer is that there is no other way than ad-hoc approaches. It also won't work in general. It's not always the case that the valid values can be listed in this way. There may be too many to display or the options may be unbounded.
    Another approach is to look at the mime type to see if it is a protocol I recognise then I know what to and were to look. For example Atom supports introspection and provides a "service description" at a "well known" location in a "well known" format.
    For the case above, how would I get the mime type without the path. I keep asking if there's a way to do this but all I get are insults from you.
  73. For the case above, how would I get the mime type without the path. I keep asking if there's a way to do this but all I get are insults from you.
    The MIME type (Content-Type) is in the HTTP Response header. I can tell you're having a bad week LOL :) I give up. I just can't help you. Believe me I've tried :) Paul.
  74. That's ad-hoc. So the answer is that there is no other way than ad-hoc approaches.

    It also won't work in general. It's not always the case that the valid values can be listed in this way. There may be too many to display or the options may be unbounded.
    James, can you elaborate on why you think this approach won't work?
    For the case above, how would I get the mime type without the path.
    As Paul mentioned, the mime type is in the response header (Content-Type). You can't construct a GET request without the path. The HTTP spec says the "GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI".
  75. That's ad-hoc. So the answer is that there is no other way than ad-hoc approaches.

    It also won't work in general. It's not always the case that the valid values can be listed in this way. There may be too many to display or the options may be unbounded.

    James, can you elaborate on why you think this approach won't work?
    First let me thank you for answering my questions seriously. I'm sorry I got snippy with you earlier. For my previous example, it might work. But consider the following hypothetical services: http://calculator.org/isprime/23443959299294421 http://www.moople.com/search/REST http://www.spelling.com/check/hifalutin You can't expect that you'll go to http://www.moople.com/search and get all the possible things you can search for just as you can't expect a list of every whole number or every possible misspelled word.
    You can't construct a GET request without the path.
    Thanks. That was my understanding and I was confused when I was told that the mime type could somehow tell me how to build the path when I need the path to get the mime type.
  76. For my previous example, it might work. But consider the following hypothetical services:

    http://calculator.org/isprime/23443959299294421

    http://www.moople.com/search/REST

    http://www.spelling.com/check/hifalutin

    You can't expect that you'll go to http://www.moople.com/search and get all the possible things you can search for just as you can't expect a list of every whole number or every possible misspelled word.
    Hi James, There is no general rule in REST that says that when you dereference a URI it must return all possible resource instances. Based on the request parameters, a URI may return nothing at all or it may return a representation that contains only a subset of available resources (e.g. result set paging). RESTful web services are still constrained by the physical limitations of the Internet (e.g. bandwidth, CPU, etc.) so it is not unreasonable to expect that a service will not return everything that it knows about simply because a client asks for it. I think it makes sense for a service to return by default some information to help the client construct a more meaningful request. This can be accomplished through one of the myriad of HTTP status codes and through the Accept response header, among others, to let the client know if it sent an invalid request and also which media types are accepted by the service. The point is that REST and HTTP provide enough basic tools to get clients and services working together in a simple, efficient, functional, and elegant way with minimal infrastructure and without excess difficulty. The basic assumption here is that the HTTP spec provides enough standardization to build web services. Personally I agree. Hope it helps, Ian
  77. There is no general rule in REST that says that when you dereference a URI it must return all possible resource instances.
    Yes this is exactly what I meant when I wrote: "It also won't work in general..." Which is what you asked me to elaborate upon. This means the process of following the path by doing successive GETs isn't a general solution. Any disagreement on this point?
    The basic assumption here is that the HTTP spec provides enough standardization to build web services.
    I've never argued to the contrary. All I'm saying is more information can't hurt and for certain purposes it could be very useful, even if you or Paul can't imagine how. I can't count the number of times someone's told me that they can't see how something would be useful until it's been done when the utility becomes self-evident. Consider that there was a time in history when many generals didn't see any value in automatic firearms. Since Paul brought up humility, the idea just because you don't see why something would be useful means it is not, is an extreme lack or humility.
  78. You seem to have a mental block here. I guess the answers are just to simple :)
    BTW, these little asides are not helping you make your case. Have the courage to insult people without hiding behind smiley faces. All these insults do is chip away at any remaining goodwill I have towards you. Earlier in this thread you referred to me as a 'friend'. Clearly you have a different understanding of what that word means than I do. We're just having a conversation. It's possible to disagree about something and not be enemies.
  79. You seem to have a mental block here. I guess the answers are just to simple :)


    BTW, these little asides are not helping you make your case. Have the courage to insult people without hiding behind smiley faces.

    All these insults do is chip away at any remaining goodwill I have towards you. Earlier in this thread you referred to me as a 'friend'. Clearly you have a different understanding of what that word means than I do.

    We're just having a conversation. It's possible to disagree about something and not be enemies.
    Hi James, These were not insults trust me. It's all light hearted. We are just talking about web protocols :) Try not taking yourself so seriously. It tooks months for the penny to drop, when I was trying to get my head around REST. The difference is that I was willing to show some humility, which is why I guess Mark Baker perservered with me. These are just gentle friendly jibes. If I wanted to insult you, you'd know. Examine your own tone and approach on a subject where you are obviously not fully versed. Civility and respect should underpin our discussions I agree, but I believe you set the tone and I was merely picking fun :) Paul.
  80. Examine your own tone and approach on a subject where you are obviously not fully versed.

    Civility and respect should underpin our discussions I agree, but I believe you set the tone and I was merely picking fun :)
    I was asking questions. You don't seem to understand that a question is not a always a challenge. Do the world a favor and never become a teacher.
  81. It tooks months for the penny to drop, when I was trying to get my head around REST.

    The difference is that I was willing to show some humility, which is why I guess Mark Baker perservered with me.
    Did you ever consider that perhaps I'm persevering with you right now? :) That's would be an example of humility :) Throughout this conversation, I've assumed that I could be missing something and if that were the case, I'd be happy. I've find the idea of you being humble quite amusing :) I've seen no sign of this trait in you :) At this point, I think your inability to consider that I might not be confused about REST is making it impossible for you to understand my point. This is something that could be resolved with a little humility on your part.
  82. I'll ask you the same question I asked Paul. It's very specific.

    Assume I have service with paths as follows:

    http://foo.com/resturaunts/[country]/[province, state, etc.]/[city]/[area?]

    example:

    http://foo.com/resturaunts/USA/CA/San+Francisco/Union+Square

    How does the web service client find out how to build this path? Is there anything other than ad-hoc approaches to defining this?
    Hi James, This is a good question. You are asking about what Richardson and Ruby call "URI design", namely designing the "surface area" of your web service. They study a number of real-world examples, including Amazon's E3 service. I think it is a very interesting aspect of developing RESTful web services, and while there is nothing in the HTTP spec that mandates a particular logical partitioning of my URI space, there are more than enough tools available to craft a sensible resource hierarchy on the web. For example, you can use URI parameters as you have shown (restaurants/USA/etc.), as well query string arguments as inputs to a formula or algorithm for example, and matrix URIs too (see http://www.w3.org/DesignIssues/MatrixURIs.html). I think the responsibility of URI design in REST is rightfully in the hands of the practitioner and I don't think the absence of a standard approach in this area is a significant limitation. Personally I think it would be boring if all RESTful web services had the same URI layout! Richardson and Ruby recommend that URI structures should be untuitive enough that your users should be able to guess the URIs of your web service. So in your example, I should be able to get a listing of restaurants in downtown Manhattan by changing the URI as follows: http://foo.com/resturaunts/USA/NY/New+York/Times+Square I'm sure in time as REST becomes more mainstream there will be a push from vendors and developers to standardize URI layouts, and already we are seeing frameworks that can generate URIs based on databases and content management systems (e.g. Apache Sling). Definitely interesting times. Hope it helps, Ian
  83. They study a number of real-world examples, including Amazon's E3 service.
    Typo - that should have been Amazon's S3 service.
  84. I think the responsibility of URI design in REST is rightfully in the hands of the practitioner and I don't think the absence of a standard approach in this area is a significant limitation.

    Personally I think it would be boring if all RESTful web services had the same URI layout!
    So now we are getting somewhere. I'm not proposing that there should be a standardized layout. All I am saying is that some standardized approach to describing the layout would have value. Along with that, simply declaring that your domain has a service and providing information about it's purpose in a standard place and format would allow for interesting tools. For example, off the top of my head, a search site for services could be created based on the descriptions in these documents. I just think that if there were such an standard available and with good community backing, RESTful services would blow WS* clear out of the water. There would be no arguments left to rationalize the use of such an over-complex and jury-rigged approach. And if done properly, it wouldn't have to change anything about how REST is done now. People would be free to ignore it if it were provided and no one would be forced to provide the information.
  85. I'm not proposing that there should be a standardized layout. All I am saying is that some standardized approach to describing the layout would have value. Along with that, simply declaring that your domain has a service and providing information about it's purpose in a standard place and format would allow for interesting tools.
    Despite Fielding's dissertation being almost 10 years old, the implementation of REST principles is still in its infancy. I have no doubt that in time a de facto or de jure standard will emerge for the description of RESTful web services. As Paul pointed out, the use of Atom and RSS feeds to publish resource information is already commonplace.
    For example, off the top of my head, a search site for services could be created based on the descriptions in these documents.

    I just think that if there were such an standard available and with good community backing, RESTful services would blow WS* clear out of the water. There would be no arguments left to rationalize the use of such an over-complex and jury-rigged approach. And if done properly, it wouldn't have to change anything about how REST is done now. People would be free to ignore it if it were provided and no one would be forced to provide the information.
    I agree, a search site for service would be interesting indeed. Given the current document formats on the Internet, is there any reason why HTML and Google (for example) would be insufficient for this purpose? Eventually a human programmer has to build the client anyway. What difference does it make if he/she has to read a few web pages to learn how, versus clicking a button to generate the client-side code? Any by the way, are we back to a tools discussion here?
  86. Please ignore typos in the previous post! :)
  87. I agree, a search site for service would be interesting indeed. Given the current document formats on the Internet, is there any reason why HTML and Google (for example) would be insufficient for this purpose?
    Can you demonstrate that it is sufficient? What tells Google that a web server supports a service and not just static data? Google is great but it's far from being a 100% reliable approach to finding the information you are looking for.
    Eventually a human programmer has to build the client anyway. What difference does it make if he/she has to read a few web pages to learn how, versus clicking a button to generate the client-side code? Any by the way, are we back to a tools discussion here?
    Please please please stop setting up the code generation straw man. The overuse of this argument is driving up the price of straw on the futures markets. There are a lot of things that can be done manually. Do you believe this means we should do them manually? For example, before RSS and Atom and all of that, people could still get the information they needed, they just had to point their browsers to the web page.
  88. Please please please stop setting up the code generation straw man. The overuse of this argument is driving up the price of straw on the futures markets.
    And you wonder why your teachers are giving up on you. One of the most precious gifts is knowledge. A student owes his teacher humility and respect. Ian and I have nothing to gain, other then perhaps people have taken the time to educate us in the past so we feel obliged to do the same. Take some advice. .Listen and suspend judgement and then think. An opinion is only useful when it is informed. Were you are now courtesy of Ian and I is that you have some knowledge. This doesn’t mean you poses understanding, and given that you haven’t used any of these approaches in anger, you are a long way of skill. The statements you are making would be bold for someone with years of RESTful experience, never mind the uninitiated like yourself. The onus is not on Ian or I to prove that the web model works, its been working fine for over a decade. If you have a superior proposal that you believe would work better then the onus is on you to describe it. We have been waiting for "the semantic web" for quite sometime, and beyond code generation, a machine-readable service description that doesn't ‘describe’ semantics is not the “semantic web”. So rather than being a straw man as you put it, this is the nub of the issue. Please explain how you intend to convey semantics in a way a machine can comprehend and act upon without human intervention. Paul.
  89. Take some advice. .Listen and suspend judgement and then think.
    Try taking your own advice. I bet you can't explain what I have been proposing.
    The onus is not on Ian or I to prove that the web model works, its been working fine for over a decade. If you have a superior proposal that you believe would work better then the onus is on you to describe it.
    I never said REST doesn't work. The onus is not on me to defend arguments I've never made.
    Please explain how you intend to convey semantics in a way a machine can comprehend and act upon without human intervention.
    How many times have I said this isn't what I'm looking for? The onus is not on me to defend arguments I've never made. If you'd taken the time to listen you'd know that this isn't what I'm talking about. You are arguing with a figment of your imagination. You haven't understood my position throughout this whole thread. You are just wasting my time.
  90. Hi James, You are a strange guy. I have asked you to describe the IDL you seek several times. If I missed it then please repeat what you have in mind. A concrete example would be great. At least then we'll know what we are arguing over :) Paul.
  91. Hi James,

    You are a strange guy. I have asked you to describe the IDL you seek several times. If I missed it then please repeat what you have in mind.

    A concrete example would be great. At least then we'll know what we are arguing over :)

    Paul.
    Right, I'll just whip up a spec in a few minutes. If you can't get what I'm looking for from what I've already posted, I don't think there's any point continuing to try. Maybe Ian can explain it to you. He seems to get the idea. At this point, I don't care what you might else you might have to say anyway. I'll look for someone else to talk this over with. Ian if you want to continue, I'm still interested in your responses.
  92. Hi James, Not listening. OK lets check the record:
    The names of resources don't tell you how to use the service for instance. They don't describe semantics (meaning) which is the important bit for most people. The RESTful constraints as applied to the web are very clear. I am not saying "any thing goes", what I am saying is that the existing constraints are sufficient.
    I am proposing a document that would describe the semantics. I don't understand your point at all.
    So please describe how you intend to ‘describe’ semantics. I don't need a spec, just an example or even a link to something similar. That can't be so hard, earlier you were claiming that it was obvious. Paul.
  93. Hi James,

    Not listening. OK lets check the record:


    The names of resources don't tell you how to use the service for instance. They don't describe semantics (meaning) which is the important bit for most people. The RESTful constraints as applied to the web are very clear. I am not saying "any thing goes", what I am saying is that the existing constraints are sufficient.

    I am proposing a document that would describe the semantics. I don't understand your point at all.



    So please describe how you intend to ‘describe’ semantics. I don't need a spec, just an example or even a link to something similar. That can't be so hard, earlier you were claiming that it was obvious.

    Paul.
    Off the top of my head this could describe how a path is built: service = resturants path country desc = A nation province desc = A province, state or other designated region city desc = The city area? desc = A designation of a section of a city
  94. Hi James,
    Off the top of my head this could describe how a path is built:

    service = resturants
    path
    country
    desc = A nation
    province
    desc = A province, state or other designated region
    city
    desc = The city
    area?
    desc = A designation of a section of a city
    OK. So what would read this? and how would it use the information? Paul.
  95. OK. So what would read this? and how would it use the information?

    Paul.
    A person could read it for one. You could transform it into a web page. Any number of tools could use it. Like a web crawler in my example above. Applications could be built to digest this data and provide it to developers in any number of ways similar to how applications are built over the APP. And yes, it's possible that code stubs could be generated from this. But that's not something I'm interested in. What I would like is a one-stop-shop for everything I need to know about the services. If this were based on the APP, then developers could receive updates on new versions or deprecations or other changes. I run into issues where we are using some completely outdated service and we didn't know until we needed support or something. I'm imagining that for tooling around this it might allow me to bind objects to service calls and responses at runtime based on the names of the path elements and possibly mappings that I've specified. That would make it easier to deal with managing lots of services with differing structures in e.g. an aggregator. You could also use something like this to define standardized path structures so that say a libraries could have a standard template that was formally defined.
  96. Let me also point out that I am perfectly open to the idea that there is already something that achieves this goal in the RESTful world. It didn't look to me that this is what WADL does. Like the article you guys both linked to, it seems to be developed for generating code and I actually heard the creator of WADL speak where he said that's what he first did with it. But I'm open to the idea that WADL already does this although it seems to be quite unpopular with the RESTafarians. The reason I first started thinking about this was that when I tried to sell the idea of REST where I worked, I was asked how we would 'publish' the services so that people could find them. I kind of started at "they just don't get REST" and ended up at, "well, I guess it couldn't hurt." The first position doesn't get me anywhere whereas the second does have potential to sway the SOAPies.
  97. OK. So what would read this? and how would it use the information?

    Paul.


    A person could read it for one. You could transform it into a web page. Any number of tools could use it. Like a web crawler in my example above. Applications could be built to digest this data and provide it to developers in any number of ways similar to how applications are built over the APP. And yes, it's possible that code stubs could be generated from this. But that's not something I'm interested in. What I would like is a one-stop-shop for everything I need to know about the services. If this were based on the APP, then developers could receive updates on new versions or deprecations or other changes. I run into issues where we are using some completely outdated service and we didn't know until we needed support or something.

    I'm imagining that for tooling around this it might allow me to bind objects to service calls and responses at runtime based on the names of the path elements and possibly mappings that I've specified. That would make it easier to deal with managing lots of services with differing structures in e.g. an aggregator. You could also use something like this to define standardized path structures so that say a libraries could have a standard template that was formally defined.
    I think I understand you. It seems that you want to create a database of all the webservices you need to access. You can do this. I don't want to do this though, which means that if you want to use my service then you are going to have to associate a description with it yourself in your format what ever that is. You can then use my URI as a reference I guess to the WSD entry in your database. Otherwise you will need to make this conpulsory for everyone. The web today supports a number of media types, formats and applications. They are all different. Some support description/introspection and others don't. The web is like a bazaar. Personally, I see this as a strength. Paul.
  98. The web today supports a number of media types, formats and applications. They are all different. Some support description/introspection and others don't.

    The web is like a bazaar. Personally, I see this as a strength.

    Paul.
    I agree that it is a strength. My whole position is that such a description be nice, not that it's a necessity. The only exception is in the 'enterprise' space where something like this is a necessity because it is declared to be so. I also need to admit that the path structure idea was lifted from the WSDL 2.0 spec where they support REST services (in theory). But in typical WS* style, they've made it far more complicated than it needs to be and not allowed for human readable documentation to be linked in, from what I can tell.
  99. The web today supports a number of media types, formats and applications. They are all different. Some support description/introspection and others don't.

    The web is like a bazaar. Personally, I see this as a strength.

    Paul.


    I agree that it is a strength. My whole position is that such a description be nice, not that it's a necessity. The only exception is in the 'enterprise' space where something like this is a necessity because it is declared to be so.

    I also need to admit that the path structure idea was lifted from the WSDL 2.0 spec where they support REST services (in theory). But in typical WS* style, they've made it far more complicated than it needs to be and not allowed for human readable documentation to be linked in, from what I can tell.
    Hi James, Thanks for the discussion. It has got me looking into different types of markup and conveying semantics. I've been looking into RDF and this particular dialect known as RDFa has really taken my fancy. Take a look at this: http://www.formsplayer.com/node/302 So I can write my service description in html, which I also annotate with RDF attributes ( a bit life myfaces with JSF tags). The same HTML can be parsed and the machine readable RDF content extracted. So one resource could play double duty. Now this is something I could sign up to. All you need to do now is create an RDF volcabulary and get the ball rolling :) Regards, Paul.
  100. Off the top of my head this could describe how a path is built:

    service = resturants
    path
    country
    desc = A nation
    province
    desc = A province, state or other designated region
    city
    desc = The city
    area?
    desc = A designation of a section of a city
    Ah, I see. Something like a formal grammar, DTD, or XML Schema that describes the ontology of your web service. Based on this, you could construct URIs in a way similar to XPath queries on an XML tree. I think you're onto something here and will have to give this more thought. Thanks for the clarification. Ian
  101. Off the top of my head this could describe how a path is built:

    service = resturants
    path
    country
    desc = A nation
    province
    desc = A province, state or other designated region
    city
    desc = The city
    area?
    desc = A designation of a section of a city

    Ah, I see.

    Something like a formal grammar, DTD, or XML Schema that describes the ontology of your web service.

    Based on this, you could construct URIs in a way similar to XPath queries on an XML tree.

    I think you're onto something here and will have to give this more thought.

    Thanks for the clarification.

    Ian
    I feel bad that I didn't do this before. I guess I really am terrible at explaining myself.
  102. I feel bad that I didn't do this before. I guess I really am terrible at explaining myself.
    Not at all! Complex ideas are not easy to explain. I'm glad that you did - this is a good one.
  103. A concrete example would be great.
    Hi James, I have to side with Paul on this one. What scenario do you have in mind? Is it a cloud computing environment where services can introspect each other without human intervention? Sort of like Google on steriods, where a search engine can index the supported HTTP methods and resources available within a web service? If so, I think something like that would be useful and could surpass the current approach of publishing documentation for human consumption (e.g. Amazon S3 REST API). This would help developers find new web services more easily. Would it help us write clients to these services, for example? When you mentioned tools I mistakenly thought you meant code generation tools. What tools are you imagining here? Public web service directories? Something like UDDI? It's fine to say don't knock something you can't envision today because tomorrow it could be great - we are only asking for more details. Until then, I think you will continue to hear the refrain that REST as it is today is good enough. (This is not to say it cannot be improved through standardization and innovation, hence the ongoing interest in your ideas.) Ian
  104. If the clients and service are both written in Java, type-safety in REST can easily be achieved.
    Who said anything about type-safety?
    What is preventing you from designing a type-safe client interface for your RESTful web service and distributing it?
    Mainly because I have no desire to and this is a terrible way to think about web services. I guess I'm not explaining myself well if this is the kind of thing people think I am looking for. All I want is a standardized description of a domain's services and how to use them. What does this have to do with static typing?
  105. There is a lot of energy in the debate around the what REST is. However the focus of this article is an approach to application abstraction that borrows from many of the concepts of REST as it is seen in web architecture. This meme has been rarely discussed. I am confident that to dismiss the approach too quickly by assuming potential problems and without realizing some of the positive implications is a mistake.
  106. Discussion of REST[ Go to top ]

    The topic of REST is obviously one which generates a lot of heat and I am glad to see it being discussed (at least when the discussion is civil). However, I feel compelled to point out that our article was not intended to be about REST, per se. Rather, we hoped to engage the reader in thinking about what principles of REST and the Web could be incorporated into modern software architecture, one possible design for such a system, and what the ramifications of such a design might be. Perhaps we should have named the article "A REST-like Core for Web-like Application Flexibility", but that sounds awkward to me. Personally, I prefer the term "Resource Oriented Computing" for this area of exploration, as it avoids 8 years of baggage: debates about what is or is not REST, whether REST is a set of principles or an implementation, and (perhaps especially) whether those who try to extend and enhance the original concepts of REST are visionaries or minions of the devil.
  107. Use case?[ Go to top ]

    I found the article very interesting. (Remember what it was about, James and Paul?) However _most_ of the subsequent discussions seemed more about ego massaging than anything else. Quite why we needed to discuss what is and what isn't REST; what did Roy do from 1993 until the publication of his thesis; whether the authors were right or not to use the term 'post hoc', just beats me! The article makes the case for applications to use a REST-like decoupling, akin to mediator/adaptor or whatever. This is what I would like to hear more justifcation of. The whole point of the web services paradigm (or indeed most RPC-like paradigms) is to hide complexity (and IPR) from the user by exposing just what is needed (the SEI). From the title I assumed the article was just another exposition of REST but this time using Java binding as an example as opposed to HTTP. However, the article seems to be making the case for this model to be applied *within* the application. Whilst the article doesn't say that every reference by one class to another should be via an intermediary, that's what could be implied. Just so that we can make run-time updates? What's the use-case, pluggable SaaS? If the app is a web service, who benefits? The client still sees an SEI. So is this just a maintenance gain? If not the SEI must change. If so, the client must be able to make complex queries to assertain what's in the evolving service. State transfer won't work here unless the new state is meaningful to the user and that would mean WSDLs, WADLs, Schemas, etc. Surely that's an unacceptable overhead as these descriptions would have to come from "deep" within the app. Every class in the tree would need a corresponding ontology. I can't help thinking of a famous quote from John McEnroe here! Nope. I just don't get it.
  108. Re: Use case?[ Go to top ]

    Roger, Thank you for your comments about the article. You are correct that we are focused on exploring the use of RESTful principles within application software. This is the first of a series of articles that will explore the fundamental concepts and the implications. We have started at the physical level and will head upwards to the logical level. We have taken this approach based on experience describing these ideas to a number of audiences and we have found that heading from the bottom upwards works best. It was not clear from this article whether we are advocating referencing all objects with a logical address. In fact we are not. A Java object that functions as an endpoint can make additional requests back to the Intermediary using a logical request or use direct memory references to a graph of other objects to complete its work. There has been a lot of discussion about WSDLs, etc., let me just say for now that we've not talked about meta information pertaining to resources and services. We have found that when we describe using RESTful principles inside of application software that discussion threads start talking about the HTTP protocol and machine-to-machine information exchange. While interesting, that is not the focus of the article. We appreciate your bringing up that point and commenting that the article is about using RESTful principles _inside_ application software. I hope you will read the subsequent articles and continue to make comments.
  109. Re: Use case?[ Go to top ]

    Thank you; I'm looking forward to the next articles. I also hope they will provide some industry-level use-cases. I still think there's a good fit to SaaS here. Also why do I keep thinking about closures..?
  110. I think this article is interesting. It addresses a different approach to creating RESTful websites (or webapps). I see no reason why this approach isn't a great idea for some projects/websites/applications. If your system is public, distributed and stateless then you are a prime candidate to implement something like this. Netkernal and similar implementations have recently been described to me as "A layer of indirection between code and resources". I think this is an excellent way to sum up the flexibility of Netkernal the approach that Tom and Randy discuss in the article. By decoupling binding and allowing the microkernal to cache and convert you could potentially save a lot of time and energy. Less time would have to be spent on optimizing and recoding the change. For instance there are a number of ways to represent the active record in a database. For example, an Active boolean flag versus the most recent date. To the developer writing the code they really don't care how it's represented. They just want records that are active. So, through using ROC these decisions are decoupled and could change between customers or implementations. This brings up a number of questions. Specifically about the netkernal implementation. Since it seems like one of those "too good to be true" solutions. What's the catch? I may not want the micro kernal doing its "automagical" thing. Is that an option? I may want fine grained control. How flexible is it and how efficient is it? Can custom type conversions be defined on resources? Can normal type conversions be optimized? Can any SQL be used (see links)? Is the SQL just pre-processed by the microkernal? How will the programmer know when a additional data is provided about a resource (ie new fields are added to a table)? Some of my questions may just require some trust on my part of the implementation. If things just work then many of my questions are moot. Also I believe this idea and philosophy is already alive in Smalltalk. The big new thing with netkernal is URIs. RESTful Smalltalk is around and easily bound to logical objects (it's smalltalk afterall). But it is not unified the way netkernal is. some additional sources: http://en.wikipedia.org/wiki/Resource_oriented_architecture http://www.1060research.com/resources/docs/ROCForDevelopers.pdf
  111. Answers to questions...[ Go to top ]

    Thank you for the comments. Your description of benefits matches what we've found in building applications - the decoupling allows developers to focus on what they want to get done (information processing) and relieves them of the code and tedium associated with dealing with specific types. To use your example of the active flag, it might have the address resource:/flags/active and its representation would be in cache (after the first access). The actual representations could be both <b&t;t</b> (an XML DOM) and a Boolean object. Client code issuing a request to SOURCE resource:/flags/active would get the representational form they need and if only the XML DOM was in cache the microkernel would request a transreption to Boolean and return (and cache) that representation. You further observe that an application could be used at a second installation where the underlying representations are different from the first and the code would not have to change. This is correct, the representational transformation would be taken care of by the microkernel. Now to your questions about the specific implementation of ROC. The implementation is modular and yes, you could remove the cache and the system would continue to work correctly - technically you would have to write and install a null cache service. Regarding the type conversions - the search for a type conversion is automatic but whether transreptors exist and how they perform the conversion is under user control. To see this let me explain how this works in a little more detail (We are also going to talk about this in the next article). When there is a mismatch between the type requested and provided the microkernel will create a new, separate logical request and issues it into the address space. It uses a verb we have not introduced - TRANSREPT. Transreptors are endpoints, just like all others in the system, except they have declared that they accept the TRANSREPT verb. The microkernel searches through the list of transreptors and asks each one "can you convert from this class to that class". When one answers affirmative, the microkernel schedules the request for processing and the transreptor endpoint returns the representation in the new form (type). There are many supplied transreptors in our system and users can add their own. Let me give you a concrete example of a provided transreptor and a reason to add a new one. Our system includes a module with database micro-services. When one of these is used the service issues a sub-request for the database connection configuration (stored in XML format in a disk file). A transreptor parses the XML configuration and returns a database connection pool with connections ready to be made to the database. (The information contained in the XML is converted to another form of the same information). Your note about statelessness is important here - each time a database service is called it re-requests the configuration information. Since it is cached, it gets it very quickly. However, all one has to do is edit the XML file to change any information and the system instantly invalidates the cached connection pool and creates a new one the next time it is requested. Similarly, if you have application configuration information you can write a transreptor to parse the configuration information and return a configuration object. Your (stateless) application services simply ask for the configuration each time they are run and they will get correct, current information. Access to SQL databases could be done in many ways. We have built a module with micro-services that query, update, etc. a relational database (we also have a module for XML databases). The information returned is in the form of a RecordSet and we include a transreptor to convert that to an XML DOM format. The usual pattern is to query the database and get the XML DOM and then apply XSLT processing - but that is just one possible way of working with DBMS data. Processing can be set up easily to invalidate the cache if DBMS data changes but explaining that gets into logical level patterns and I would prefer to leave that for a subsequent article. If the structure of the database changes (a column is added) then the XML document will include this. If you use XPATH to access the XML document then your code will not break, it simply will not know to get the new column. This points out a difference between types and information. The ROC system will automatically convert types but if the shape and form of information changes, then the logical level processing might have to change also.