A RESTful Core for Web-like Application Flexibility - Part 2

Discussions

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

  1. In A RESTful Core for Web-like Application Flexibility - Part 1, Randy Kahle and Tom Hicks lay the groundwork for a discussion on the principles of computing using a Representational State Transfer (REST) style. In this article, they expand that discussion to present a microkernel architecture that provides logical address resolution and other services. Read this article
  2. In part 2 we have a new term: ROC.
    This name comes from a fundamental point about the approach: resources are identified by URI addresses and are requested by clients. You might think of ROC as a refinement or evolution of RESTful design thinking, applied to application software.
    Change URI to IOR and you have a CORBA system. With a NamingService with the role of "logical addresses to physical endpoints" mapper. My previous post to part 1 (http://www.theserverside.com/news/thread.tss?thread_id=50132#264158) obviously applies to the discussion about intermediary and Transrepresentation. Now Caching.
    According to the REST design approach, returned resource representations are copies of the information located at a resource address. And, importantly, they are immutable copies of the information which was current at the time of the request.
    This is not due to REST design approach. This is true since the epoch. Even with RDBMS what you get with a ResultSet is a copy of what stored in the backend. See this, please http://www.theserverside.com/news/thread.tss?thread_id=50244#265627
    Because the representation is immutable, there is no difference between recomputing the representation and reading the immutable copy - as long as the information managed by the endpoint has not changed. This leads to the idea of using a cache to save computed resource representations and somehow keep track of the validity of the information.
    I would be surprised if not. It is still not clear to me if the articles deal with an approach (REST) or a product (the microkernel). If we are talking about an approach,I don't understand the implementation details (caching, scheduling, load-balancing). If we are talking about a product, OK, but, please, don't try to sell old things with new names. Guido
  3. This is not due to REST design approach.
    This is true since the epoch.
    In regards specifically to REST over HTTP, there is a definition that some of the verbs (notably GET) used in the protocol are idempotent and, therefore, potentially the results can be cached. The detail, again specifically to HTTP, is that the infrastructure is aware of this property of the request, and therefore the infrastructure can involve itself "automatically" in the caching decision making process. This infrastructure capability is aided by HTTP specific headers that can be used to control caching. The key take away here is that the caching decision is at the protocol level, not necessarily at the API level, though obviously the API can affect the caching behavior. A complaint about SOAP over HTTP is that since every request is an HTTP POST, which is not considered idempotent or cachable, the infrastructure can not make any caching decisions. Rather, the API must do that at the implementation level. Now, there's nothing stopping someone from leveraging SOAP headers, and using naming conventions that an intermediary system can use to "automate" caching at the infrastructure level. It would just be required to introspect the SOAP payload, but this is no different that introspecting the HTTP request. The only issue is simply that there isn't any current wide spread infrastructure that provides this kind of functionality for SOAP over HTTP, but at the HTTP level, these types of caches are ubiquitous. So, while, sure, caching has been around since cavemen stored dinosaur jerky in their caves, one of the aspects of REST over HTTP is leveraging the in built caching functionality of the HTTP protocol.
  4. This is not due to REST design approach.
    This is true since the epoch.


    In regards specifically to REST over HTTP, there is a definition that some of the verbs (notably GET) used in the protocol are idempotent and, therefore, potentially the results can be cached.
    I don't see the relation between idempotent verbs and caching. Idempotent means that the operation execution doesn't change the resource. What you cache is the result of the execution. What does prevent you from cache a POST result, provided that the result is the state of the resource after the change (i.e., what you would get in a subsequent GET) ?


    The detail, again specifically to HTTP, is that the infrastructure is aware of this property of the request, and therefore the infrastructure can involve itself "automatically" in the caching decision making process.

    This infrastructure capability is aided by HTTP specific headers that can be used to control caching.

    The key take away here is that the caching decision is at the protocol level, not necessarily at the API level, though obviously the API can affect the caching behavior.

    A complaint about SOAP over HTTP is that since every request is an HTTP POST, which is not considered idempotent or cachable, the infrastructure can not make any caching decisions. Rather, the API must do that at the implementation level.

    Now, there's nothing stopping someone from leveraging SOAP headers, and using naming conventions that an intermediary system can use to "automate" caching at the infrastructure level. It would just be required to introspect the SOAP payload, but this is no different that introspecting the HTTP request.

    The only issue is simply that there isn't any current wide spread infrastructure that provides this kind of functionality for SOAP over HTTP, but at the HTTP level, these types of caches are ubiquitous.

    So, while, sure, caching has been around since cavemen stored dinosaur jerky in their caves, one of the aspects of REST over HTTP is leveraging the in built caching functionality of the HTTP protocol.
    Hmm, wasn't stated in the article that they were not talking about REST over HTTP ? What I was trying to say in my post is that there is, how could I say, some confusion. Maybe I was right. Guido
  5. Idempotent means that the operation execution doesn't change the resource.
    Hi Guido, Actually, idempotent means that the operation can be executed many times, but subsequent invocations have the same effect as the first one. Deleting a resource ten times has the same effect as deleting it the first time. What you are describing is safety. A safe operation (e.g. GET) does not change resource state. Ian
  6. Guido, Yes, there are other examples of logical address to physical endpoint mappings. JNDI is another one. There are differences too. In the approach we are discussing the binding is transient. The client uses a particular endpoint for one request and then the binding is discarded. In other uses of logical to physical endpoint bindings the goal is to establish a long-lived relationship. Also, our approach is independent of type. It's been a long time since I've looked at CORBA, but I believe there is very strict type mapping between the client and the endpoint and the called service. We are not saying that caching is new to ROC. What we are trying to point out is that, because of ROC's abstraction, immutability and the indirection, caching is more effective in an ROC system compared to others. In an ROC system any and all requests are candidates for caching. This compares to other systems where caching is added to specific parts of a design. We created the term "Resource Oriented Computing" to describe the abstraction for several reasons. As the comments to the first article indicate, the term "REST" creates a lot of discussion threads which are focused on HTTP and specifics about the protocol. What we have found is that the ideas behind REST are independent of HTTP. By using a different term we hope we can talk about REST and RESTful designs while keeping our discussion apart from particulars of HTTP. Furthermore we have found that what is really important are the resources themselves. I think this will become clearer when we talk about the logical level in a subsequent article. Regarding your question about whether this is a discussion about an approach or product - ROC is a new approach based on new concepts and new combinations of existing concepts and ideas. However, this is not hypothetical - there is a concrete implementation of the approach and we know that it works. We also know that others are working on similar ideas. There was a request in a post to the first article asking us to present real world examples of use - we will do so in a subsequent article. Randy
  7. Guido,

    Yes, there are other examples of logical address to physical endpoint mappings. JNDI is another one. There are differences too. In the approach we are discussing the binding is transient. The client uses a particular endpoint for one request and then the binding is discarded.
    It is not the place to resume a CORBA discussion, but you can do the same.
    In other uses of logical to physical endpoint bindings the goal is to establish a long-lived relationship. Also, our approach is independent of type. It's been a long time since I've looked at CORBA, but I believe there is very strict type mapping between the client and the endpoint and the called service.
    See above.


    We are not saying that caching is new to ROC.
    I have said a different thing. I have said that the following
    According to the REST design approach, returned resource representations are copies of the information located at a resource address. And, importantly, they are immutable copies of the information which was current at the time of the request.
    is not a property specific of resource, ROC, REST of whatever. As I said, this is true also for plain data read from a ResultSet.
    What we are trying to point out is that, because of ROC's abstraction, immutability and the indirection, caching is more effective in an ROC system compared to others. In an ROC system any and all requests are candidates for caching.
    I guess it is easier because of the mediator.
    This compares to other systems where caching is added to specific parts of a design.

    We created the term "Resource Oriented Computing" to describe the abstraction for several reasons. As the comments to the first article indicate, the term "REST" creates a lot of discussion threads which are focused on HTTP and specifics about the protocol. What we have found is that the ideas behind REST are independent of HTTP. By using a different term we hope we can talk about REST and RESTful designs while keeping our discussion apart from particulars of HTTP. Furthermore we have found that what is really important are the resources themselves. I think this will become clearer when we talk about the logical level in a subsequent article.

    Regarding your question about whether this is a discussion about an approach or product - ROC is a new approach based on new concepts and new combinations of existing concepts and ideas. However, this is not hypothetical - there is a concrete implementation of the approach and we know that it works. We also know that others are working on similar ideas. There was a request in a post to the first article asking us to present real world examples of use - we will do so in a subsequent article.

    Randy
    If ROC is a hammer then any distributed system where participants can be effectively modeled as nails can gain successfully adopt the approach. But, I fear that not all the systems are made of nails. And that there are a lot pseudo-technician out there not able to cacth the difference. Guido
  8. It is still not clear to me if the articles deal with an approach (REST) or a product (the microkernel).
    Google says: "Randy Kahle is the Director of Marketing for 1060 Research". It appears that the second article forgot to include the "About the authors" section (which you can find in the first article). To presume an answer to your question, the article likely deals with the approach that the product uses. (Unfortunately, some of these things can be a bit hard to tell, since -- believe it or not -- some vendors pay for space on the site, thus disguising their marketing as technical content.) Peace, Cameron Purdy Oracle Coherence: Data Grid for Java and .NET
  9. (Unfortunately, some of these things can be a bit hard to tell, since -- believe it or not -- some vendors pay for space on the site, thus disguising their marketing as technical content.)
    Hi Cameron, Without prejudicing this article, I think the point you raise is a valid one and a symptom of a wider disease. Not that long ago third-party APIs were merely a convenience, allowing programmers to re-use code written by others. Unfortunately communities like Java/J2EE have promoted the idea that APIs and libraries can be viewed as black boxes that magically solve problems without the programmer having to know what is going on inside. This is attractive because it suggests that you can use lower skilled programmers if you choose the right APIs. This is an attractive proposition for Managers who are wondering how they can de-risk their projects and save money at the same time. I agree that these authors would do better to declare any interest, but I fear this would do nothing to raise the level of discourse. Most Unix hackers know a fair amount about the internals of Unix and how it is implemented. I don't think the same can be said for most J2EE hackers. Whilst this remains the case we will continue to see articles that suggest that a given API/tool is the solution to all our problems without the details to back up such claims. Why? Because it is assumed that we are too dumb to evaluate the details for ourselves. In our eagerness to "out-source" thought itself, we have blunted our collective ability to assess alternatives for ourselves. I guess my point is that we have ended up with the "dumbed down" community we deserve. Paul.
  10. Cameron and Paul, I am not sure why the author information was dropped from this article. Our intent is to reveal the essence of what has been learned about a new approach to building application software and share it with the community. We know of at least one project that is based on our findings and we anticipate others as this approach is explored and understood. We have an implementation of the approach and the source code is available on http://www.1060.org. Our approach is very different from the current industry norm of using APIs and frameworks. Unfortunately, what we are heading towards - a discussion of programming at the logical level, is covered in a future article. This series has started at the bottom (with binding) and heads towards the logical level abstraction because we have found that this is the best path to take with very technical audiences such as TheServerSide.
  11. Google Android[ Go to top ]

    This is very similar to Google Android Intents. Do they have the same semantic? Android: Intent intent = new Intent(Intent.PICK_ACTION, Uri.parse("content://contacts"); ROC: Request req = context.createRequest("resource:/customers/"); req.setVerb(Request.SOURCE); Zurdo.
  12. Re: Google Android[ Go to top ]

    Zurdo, Interesting... I don't know Android but there does seem to be a syntactic similarity that seems to imply a semantic similarity. I'll try to investigate and respond. Maybe someone who knows Android can help us out. Randy
  13. Why?[ Go to top ]

    You have chosen to adopt the REST architectural style for what looks like a non-distributed application. You seem to want late-bound properties yet you have chosen an early-bound language. Why? In Roy Fieldings dissertation: http://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.htm He is careful to describe the strengths and weaknesses of a number of network-based architectural styles in section 3. He then goes on to describe the design of the web architecture in relation to the specifics of the web requirements in section 4. Finally he describes the REST architectural style in section 5. Here you choose to adopt the REST style without reference to the specific problem you are trying to solve. This makes it very confusing. If we were to restrict our verbs to to just one: "SEND", then a late-bound, messaged based language like Smalltalk would be consistent with what you describe. I would not call this RESTful though, I would just call it a late-bound, message based language. Perhaps it would be useful if you started off with a use case (like fielding does in section 4), before going on to describe your solution. Without a use-case we don't know the problem you are trying to solve. Paul.
  14. Microkernel & Apache Sling[ Go to top ]

    Randy, Thanks for this thoughtful series of articles! Personally, I am convinced that the REST/ROC approach will simplify many content oriented applications and their respective architectures. Just one question: to what extent would you agree that Apache Sling is a ROC microkernel? -- Juerg
  15. Bloated with redundancy[ Go to top ]

    I don't want to criticize the REST approach or the basic ideas of those two articles, but I found them very bloated with redundancy. Especially the second one is repeating too much of the first (why? this is not a newspaper - we can use the link to the first one). And after reading both articles I am still waiting for the exciting matters... Best wishes Marco
  16. Re: Bloated with redundancy[ Go to top ]

    I don't want to criticize the REST approach or the basic ideas of those two articles, but I found them very bloated with redundancy. Especially the second one is repeating too much of the first (why? this is not a newspaper - we can use the link to the first one). And after reading both articles I am still waiting for the exciting matters...

    Best wishes
    Marco
    Marco, I'm glad that you've had the patience to stick with us through both articles. I view a little redundancy as a good thing; it reinforces learning. Also, restating things in a different way helps people who may be coming from a different background than you or I. In our experience, the TSS crowd tends to have a strong grounding in OO programming (especially Java) and to be very detail-oriented. But, we believe there is also a contingent of TSS readers who work at the design and architectural level. For both sets of readers, we felt it was important to emphasize the foundational concepts on which the ROC architecture is based. As to the "exciting matters", we have already submitted article #3 (Logical Level Programming) for publication and I think you will find it to be "meatier". regards, -tom
  17. References?[ Go to top ]

    David Parnas once developed a language called BLOWHARD (Basic Language – Omniscient With Hardly Any Research or Development) as a reaction to the many new languages being developed in the 1970s. He claimed BLOWHARD was the only language that lives up to all the hype concerning language design, namely: o It is a notation for a computation. o It is a convenient way to instruct a computer. o It enforces rule of good practice. o It provides a means of invoking previously written programs. BLOWHARD contains only the empty (null) statement. Comment on the virtues of BLOWHARD with respect to some of the languages discussed in the text with respect to: verification and correctness, ease of translation, ease of understanding, ease of optimizing the execution behavior, etc.