One of the promises of the REST architectural style is an increase in reuse – a design done with resources is supposed to yield more options for reusing information and logic. REST inventor Roy T. Fielding has talked about "engineering for serendipity" and suggested that this should be one of a REST designer's main goals.
Planning reusability is hard, designing for unforeseen reuse might be even harder. In this QCon London 2008 talk, Steve Vinoski presents some of the barriers to reuse found in typical distributed systems development approaches, and discusses how REST not only helps overcome some of these barriers, but also leads to potentially significantly increased chances for achieving serendipitous reuse.
Steve explains how he, as a "CORBA guy", became involved with REST, and how his failure to convince his employer to adopt this ultimately led to his leaving. After discussing the "descendants of RPC" (CORBA, EJB, .NET, SCA, SOAP, WSDL) and message queueing alternatives, he outlines the Unix ecosystem as an example of one where a uniform interface furthers reuse (e.g. a tool like awk, written ages ago, can still be combined into brand new tools via a pipe).
He continues with a refresher on HTTP's uniform interface, which enables visibility into interactions, caching, monitoring, mediation, strong implementation hiding and a simplified overall architecture. Steve points out that most of what he's done in the past dealt with the effects of having a specific interface (generating code, creating the runtime infrastructure), and that most of this disappears in REST.
After covering other REST topics, such as representation formats, the role of media types registered with IANA, and the hypermedia constraint, he discusses wat he considers to be the most important benefit: RPC-oriented systems try to extend language paradigms over the wire, which encourages variation in both methods and datatypes, which ultimately can't scale, which REST is purpose-built for distributed systems, properly separates concerns and allows constrained variability only where required.
Watch the full presentation (60 minutes) for more details about REST, reuse and serendipity.
Community comments
Type System Illusions?
by Troels Knak-Nielsen,
Re: Type System Illusions?
by todd hoff,
Re: Type System Illusions?
by Stefan Tilkov,
Re: Type System Illusions?
by Troels Knak-Nielsen,
Re: Type System Illusions?
by Steve Vinoski,
Re: Type System Illusions?
by Tjerk Wolterink,
Re: Type System Illusions?
by Steve Vinoski,
Re: Type System Illusions?
by Steve Vinoski,
Type System Illusions?
by Troels Knak-Nielsen,
Your message is awaiting moderation. Thank you for participating in the discussion.
Around 00:15:00 (The slide "Type System Illusions"), he says something along the lines of "Types can't be enforced over RPC". Could someone explain what did he mean with that statement?
Re: Type System Illusions?
by todd hoff,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think it means types are defined by code that manipulates the data sent through an RPC. An RPC is just a data definition. It doesn't know a bank deposit shouldn't be negative, for example, which a type would know.
Re: Type System Illusions?
by Stefan Tilkov,
Your message is awaiting moderation. Thank you for participating in the discussion.
With an in-process call, a static type system protects you (to a certain degree). If a method invocation is done over the wire, you have no idea whether the two communicating programs have been built with the same language, let alone the same version of the exact same interface.
Re: Type System Illusions?
by Troels Knak-Nielsen,
Your message is awaiting moderation. Thank you for participating in the discussion.
So, in other words, runtime violations of the protocol could occur? I thought he perhaps meant there was some fundamental issue which had alluded me. All that is saying is that when you have multiple parties involved, you can't guarantee that protocols are respected. But that's hardly the fault of the protocols, is it?
Re: Type System Illusions?
by Steve Vinoski,
Your message is awaiting moderation. Thank you for participating in the discussion.
Stefan's explanation of what I meant by "type system illusions" is correct.
I've heard many arguments over the years that using Java, C++, etc. for distributed systems development was very important and beneficial because of the type safety they offer. I probably mistakenly made such arguments myself at one point or another. When you compile a regular program, the compiler/linker/loader can detect type mismatches, signature mismatches, etc. because what's being produced is pretty much a monolithic entity. However, the same is not even close to being true in a distributed system given that what's at the endpoints can vary in terms of not only implementation languages, but also versions of interfaces, transfer syntax, and compile-time types.
In reality any claims of type safety offered by such languages in a distributed setting are misguided because these languages can offer no safety beyond what they provide to ordinary non-distributed programs. Once a message or RPC call leaves a particular address space, the language can no longer enforce or guarantee any static type safety, especially in a multi-language system. There are ways to achieve some degree of safety by sending the actual code that implements the types as part of the call, but that trade-off makes handling multiple languages difficult or even impossible, which automatically limits your scalability, flexibility, and adaptability.
Re: Type System Illusions?
by Tjerk Wolterink,
Your message is awaiting moderation. Thank you for participating in the discussion.
You say RPC calls try to look like local calls:
Thats not totally true: the programmer must be aware: to handle the errors that only happen with remote calls. Some EAI systems even use transaction management for remote calls in order to prevent the problem you name: suppose the client crashes before the server can respond. Distribute systems theory exactly solve these kind of problems.
Coupling between source language and Interface Description:
The code generation and the coupling with the source language is not really that true, because Web Services are based on XML Schema.
About the Type Safety Illusion:
RCP in general doesnt provide type safety, but certain RCP techniques like Web Services do: they are based on XML Schema language. So type safety is guaranteed. So I basically do not agree with you.
Off course it depends on the RCP technique you use.
I agree that the sevices of a system must be specified before you do coding. So generating an IDL from sourcecode is not really good.
In fact i do research about Domain Specific Languages to first model the domain of interest: the business services etc.
Re: Type System Illusions?
by Steve Vinoski,
Your message is awaiting moderation. Thank you for participating in the discussion.
I hear this sort of response quite often. The very nature of RPC is that it was invented to make remote programming look local; you may want to read RFC 707, where RPC was first described. Also, the term "RPC" does not refer to "just any network message" — you may want to go review my slides from QCon London 2009.
There's more to it than just error handling. For example, there are sometimes issues related to impedance mismatch between the types in the distributed system and the local programming language types used to represent them, and there are issues related to idempotency and how to recover properly should a failure occur somewhere within a stateful interaction. Such issues can significantly impact RPC-oriented development, trust me.
Ah, so you write all your applications in XML Schema! I was unaware it was a programming language. ;-) So you're telling me that with XML Schema, there is no impedance mismatch between it and any programming language? In other words, mapping between any programming language and XML Schema is entirely faithful and lossless?
XML Schema does not solve this problem, since you have no way to guarantee that the schema node A uses is exactly the same schema that node B uses, unless you send the whole schema document along with every single message and receivers always validate all messages, neither of which does much to help performance or scalability. XML Schema is no different than any other type system in this regard.
Instead of focusing on XML Schema and Web Services, which IMO is a dead end, I suggest you should devote your research to RESTful web services. You'll get far more benefit from it for your own work, perhaps leading to systems of significant scale that would be well beyond anything achievable with XSD and WS-*.
Re: Type System Illusions?
by Steve Vinoski,
Your message is awaiting moderation. Thank you for participating in the discussion.
Keep in mind that RPC hides protocols. All the programmer sees are the functions to call, the types to pass, and the expected return type. That in and of itself is a fundamental problem.