I think perhaps you didn't understand my reply to you. See inline.
On 7/10/06, V D <[EMAIL PROTECTED]> wrote:
Thank you for the post. I check out your links and there's not much more on the site than the old site. There's some interesting links though. I did check some of the links out. Please reread my original post. I think you mis-read it. I know that REST is not the same as RPC. I was discussing its importance and relevance. Here are some point: 1) Identify item by universal resource id is definitely different than another method. But I don't see how this is significant or better than SOAP. It would be nice to see a concrete argument on what is the problem, and how this architecture solves it better than old/alternative architectures. I see references to Corba, DCOM and RMI and mention of their failures. But is it true that they "failed" because lack of (or mishandling) things that REST provides? With identifying objects, I think if there is an easy way to locate things, and if session less, a same way of accessing the old object and the new object is good enough. Certainly, for the web, since it's easy to remember the web address, it's good thing. However, take Corba for example, the early Corba, they tried to use the stringified object id which is very hard to remember (unless you're one the million out there) to locate object. Yes, it's unique and it's standard, but I think that was one of the reason Corba failed.
REST was originally defined to support hypermedia systems, but the architecture can work as well for distributed computing systems. A URL uniquely identifies a resource, and it permits any system to reference the resource via the URL and to perform some basic operations on it -- GET, PUT, POST, DELETE -- regardless of the type of systems involved. CORBA, RMI, DCOM, etc use object IDs, remote references, etc, but all of these idenitfiers are middleware-specific, and therefore much less versatile. URLs are a tremendously valuable invention of the Web and REST. In fact, many other distributed computing systems have adopted URLs as a universal identification scheme.
2) Stateful and stateless. Mention of cookies to illustrate the point, not saying cookie imply stateful. The point is that the web need stateful and stateless. With only stateless, you don't have shopping card, login session, etc. In fact, checking one of the referenced page from your link, I found that it uses some kind of token to keep the login. That's stateful. Stateful is a great thing. Since web didn't provide stateful (like session bean in EJB) natively, people have to work with cookies, with rewrite url, hidden form field, etc. to simulate this behavior. This does not discuss how to implement stateful efficiently or correctly. It means how important it is that people are willing to jump through hoops to get this work. I believe the success of the web has nothing to do with stateless nature of it. I also went across an explanation of application state and resource state. It says stateless in REST refers to resource state. While authentication information is application state. Is this unnecessarily complicated? There's persisted objects, session objects and session-less object. Are they trying to refer to persisted objects as data in the resource state? Not confusing, but introducing something with a different name does not add value. Additionally, how is this any different than other architecture with respect to stateless?
I think you don't understand what I mean by stateless vs stateful interactions. You absolutely can implement shopping carts, login sessions, etc, using stateless interactions. In a stateless interaction, the client must provide some information--such as a cookie or token--to the service on each message exchange, which the service uses to re-establish the current session state. The state is persisted between interactions, and the cookie or token provides a reference to the session state. If for some reason the session is terminated, you can always reestablish the session and continue where you left off. In a RESTful application, the service is likely to create a new resource (with a new URL) to manage the state. The client re-establishes its state simply by performing operations on its new, dedicated resource. In a stateful interaction, the client does not need to provide any information to the service to re-establish the current session state -- the service maintains an open session, and the session is responsible maintaining the state. The state is not persisted, and if for some reason the session terminates, so does the state. You cannot re-establish the session. You must start over from the beginning. The first approach is much more scalable and robust than the second one.
3) Limited, well defined number of operations on a object. Ok, pass the point of how to reference an object (whether using url, resource url, resource id, or whatever way like EJB's object lookup method), what can you do with it. REST prefer using a limited predefined set of operations to set/get attributes or object states. I think SOAP can do it with just a POST all the time. But a bunch of operations it defines to manipulate object or objects, translating to a bunch of set/get in REST is not that much different, with the EXCEPTION that set/get in REST will set some data, and get some data, while operations do things. This means the server does things instead of just blindly return information, or persisted some information. So, true, they're not the same, but what good if SOAP: allow users to set/get information, and do things, while REST: allow users to set/get information.
I think this constraint is the center of the controversy regarding REST. I'm not convinced that a uniform interface really does provide such significant advantages over a customized interface. For hypermedia applications -- absolutely. For transactional systems, I'm less convinced. The REST proponents claim that the uniform interface makes REST applications more extensible and scalable, but from my perspective, it merely shifts the burden of semantic understanding to the application level.
4) Hypermedia. According to dictionary.reference.com, its definition is: A computer-based information retrieval system that enables a user to gain or provide access to texts, audio and video recordings, photographs, and computer graphics related to a particular subject. You said it's not just links inside content, but it's a way to uniquely locate and retrieve any of these data bit types and retrieve them in the 1st class citizen. If content is important, if accessing to them is important, if reference to them is important for a particular type of application, give first-class citizen treatment to make it easy is not a new architecture point of view. It's just engineering. For the type of apps the emphasizes other things, then this does not make sense. You can argue that REST is not for everything. This is not the point, the point is that this item #4 is not an architecture point. It's just a common requirement when you doing an engineering job.
Some people argue that REST is simply an implementation style, and not a true architecture. Based on your comment, I suspect you fall in that camp. If you adopt a service-orientated perspective, then I agree -- REST is merely an implementation style, and true resources should have unique identifyiers -- good engineering. But a truly RESTful design (in which the core unit of design is resource) will be quite different from a SOA design (in which the core unit of design is a service). I suspect you aren't aware, but I am not a huge proponent of REST.
From my perspective, service-orientation is much easier to understand
that resource-orientation, and SOA is hard enough to understand. I suspect that a lot people that talk about REST don't really understand what it is. But I also recognize that there's a ton of great stuff in REST, and it is probably the best architecture for applications that must support Internet-scale requirements. It definitely has proven itself to be a phenomenal system for supporting hypermedia. If you are a student of distributed computing, it's worth your time to study REST. Don't just read about it. Design a few systems. Build the same system using a service-oriented versus a resource-oriented approach. Join a REST discussion list. Once you've defined your REST system, get it critiqued by the REST community. You may discover that what you thought was a resource-oriented system is actually tunneling RPCs. Resource-orientation is, in fact, a very different mindset. Anne
Anne Thomas Manes wrote: > V D, > > Please keep in mind that Wikipedia is not necessarily the source of > universal truth. > > As a starting point for studying the REST architecture, I suggest the > RestWiki: > http://rest.blueoxen.net/cgi-bin/wiki.pl > > Of course, the primary source of truth about REST is Roy Fielding's > dissertation, which normally can be found at > http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm, but for > some reason today, I'm getting a 403 Forbidden error on that link. > > REST is an architectural style in which the core unit of design is a > resource. Every resource has a unique identifier (a URL). Components > communicate by exchanging representations of the resource rather than > by directly performing operations on the resource. Each resource > exposes a uniform set of methods for exchanging representations -- for > example (from HTTP), GET, PUT, POST, DELETE. (REST doesn't require use > of HTTP, but HTTP is inherently RESTful.) All interactions with the > resource are stateless. > > This approach is fundamentally different from an architectural style > in which the core unit of design is a service (SOA). > > Let me provide an example. Let's say that you want to build a system > that allows users to manipulate lightbulbs. > > In SOA, the core unit of the design is a service which exposes some > capability (managing lightbulbs). A service exposes that capability > through a set of operations: > - locateLightbulbs > - input (query parameters) > - output (array of lightbulb identifiers that match the query > parameters) > - queryLightbulbs > - input (array of lightbulb idenitifers) > - output (array of lightbulb idenitfiers and their states -- > on/off/luminosity setting) > - setLightbulbs > - input (array of lightbulb identifiers and state settings) > - output (void or confirmation/fault) > > In REST, the core unit of the design is the resource that you want to > manipulate (the lightbulb). Each manageable lightbulb is a unique > resource and has a unique URL. You manipulate the resource by > exchanging representations of it. > - GET retrieves its state > - PUT sets its state > - POST adds additional state, such as its location and its wattage. > > Notice the differences in the design. In the service-oriented > approach, you manage all lightbulbs through one service. The service > has a unique endpoint URL, but each lightbulb does not. The service > encapsulates the actual resources. You manipulate a lightbulb by > invoking an operation that is specific to this service (i.e., not a > uniform API). You identify the lightbulb(s) that you want to query or > set as part of the content of the invocation message. > > In the resource-oriented approach, you don't have a central service. > Each lightbulb has a unique URL, and you manipulate the lightbulb > using a uniform interface. > > More comments inline below... > > On 7/1/06, V D <[EMAIL PROTECTED]> wrote: >> >> I tried to ignore this REST term for a while. But it keeps come up, so >> I take a plunge and check it out. Yes, people often refer it to >> http://en.wikipedia.org/wiki/Representational_State_Transfer >> >> So, I check it out. >> >> My first impression: it's non-sense. My deeper impression, it's nothing >> more than a catch phrase. Yes, for those who bought into this >> term/architecture may get offended, but let me explain. > > You probably won't offend people. They'll just assume that either: > > a) you haven't spent enough time studying REST to understand it > or > b) you're too thick to understand it > > REST is not nonsense, and it's way more than a catch phrase. It's just > that it's a very different way to design systems. If you don't spend > the time to grok it, you won't understand it. > >> First, the term REST, a noun to me because it IS an architecture name. >> Then why would RESTful? it sounds like REST is adjective. A catch >> phrase. > > REST is a noun -- an architectural style. > RESTful is an adjective applied to an application or system that > complies with the REST architectural style. > > What's a catch phase other than a shorthand way to reference > something? REST is as much a catch phrase as SOA is. That doesn't mean > that the term doesn't have a true meaning. > >> Second, reading the page, it is recognized that REST is very broad. So, >> using this page alone, there is no way I cannot develop a system that >> communicate with others in a standard way. Communication without >> standard? It's not communication. For example, wikipedia compare REST >> to RPC. RPC is not a standard. You cannot say, let's program it in RPC >> and we connect to each other. > > As I said at the beginning, Wikipedia is not necessarily the source of > all truth. Obviously, in this situation, it doesn't provide enough > information to be useful to you. > > It's inappropriate to directly compare REST with RPC. It's also > inappropriate to directly compare REST with SOAP. (It's more > appropriate to compare RPC or SOAP with HTTP. It's also more > appropriate to compare REST with SOA.) REST is not a communication > technology; it is an approach to designing systems. RPC is a > communication technology for invoking operations. You typically would > not use RPC in a RESTful system because RPC is designed to invoke > methods, not to exchange resource representations. > >> Third, principle. This things based on stateless, client/server >> protocol. With a big exception that the web is not just stateless. >> Taking the "stateful" out of the web, you cut most of its usefulness. >> Without cookies and url re-write, there's no commercial app on the web. >> Yes, you can do something else like cookies, like submit something to >> make it like cookie, but cookie is not the point, the point is >> stateful. "stateful" is good. Repeat that 10 times. > > Use of cookies does not imply "stateful". In fact, cookies enable you > to make what would normally be a stateful interaction stateless. > > Stateful implies that the server maintains active (non-saved) state > about your specific session between two interactions, and if for some > reason your session terminates, all your state goes away, and you have > to start your process over. If you use a cookie rather than > maintaining state, then you can always resume your interaction just > where you left off by providing a reference to saved state (the > cookie). > > Haven't you ever had an experience on the web where you hit the back > button, and the server says that it can't take you back -- instead you > must resubmit and refresh the screen? That's stateful. And it's > definitely not RESTful. > >> The 2nd principle, well-defined operations. Take the web for example: >> post, get, put, delete. How is this different from SOAP? They even use >> less operation. Get/Post all the time (this may be not accurate, but >> the point is that they also use the web's limited, well-defined >> operations). But that's not enough, so they build on top of its any >> operations needed. This is so that people can do things differently on >> it. So, one can argue that REST does not need that and can handle the >> job. Let's see. With REST, can one update a shopping card? No, you >> can only do a GET/PUT/POST/DELETE? Sure, you can update a shopping card >> using REST. They use one of the operation above, but I am sure they use >> some way (through url?) to signal the update of the shopping card. How >> is this different from SOAP over web? Nothing with respect to the >> well-defined operations. Same basic web operations, with some way to >> signify a higher level of operation. The difference is in how that >> higher level of operation is defined. Whether in the header (or url), >> in the body, what format, etc. > > You need to understand the basic concepts of REST for this to make > sense to you. REST is *resource* oriented rather than *service* > oriented. SOAP (typically) is service oriented rather than resource > oriented, although you can use SOAP in RESTful applications. > > Resources are things (nouns). Services expose a set of capabilities > that can perform operations (verbs) on things. > > In a typical SOAP application, a service exposes a set of operations > which are unique to the service (i.e., it does not expose a uniform > interface). An inbound SOAP message conveys a request to invoke one of > those operations, which, in Axis, translates into a method invocation > on a Java object. Very few people use SOAP to exchange representations > of resources. > >> The 3rd principle, universal syntax. The same URL mechanism is used to >> access resource. How is it different from SOAP of accessing a web >> service end point? Look up and things like that is only required if you >> don't have the URL. One can argue that they are not different, but that >> is the principle. But what make this principle unique? People have a >> standard on IP/port to communicate in TCP/IP. They have standard (at >> least in the US) on snail mail address to get/send mail to someone. One >> thing I can see that SOAP may have 1 end point, but different operation >> may give you different meaning, different resource. This is another way >> to put another abstract level above the URL. So, my interpretation is >> that REST use different URL for different resources, and different >> operations. While SOAP has a single end point, the depend on the >> request, they can get different resource, or issue different command. I >> think SOAP is better. This concept is like package in Java, or >> namespace in general. You have [endpoint,operations] in SOAP or >> endpoint_operations in REST. One can argue that SOAP does not have a >> standard on the operations. This is the beauty of it. There's millions >> of different apps out there, who know what operations to defined. If >> REST forces you to 5 operations for example (this is not the case), what >> good is it? Otherwise, if it defines millions of operations using the >> same way to represent operation (URL), but the meaning of each operation >> is depend on whoever make it defined it, then there's no relevant >> difference with SOAP here. > > Again, you need to grok the core principles of REST for this to make > sense. > > In REST, each resource has a unique URL, and the only things you > *need* to be able to are: > > - get its state (GET) > - update its state (PUT) > - add additional state (POST) > - delete its state (DELETE) > > With SOAP, you don't expose each individual resource, you expose a set > of operations that can operate on some arbitrary set of resources. The > resources are encapsulated by the service and its operations. It's a > fundamentally different design approach. > >> The 4th principle, the use of hypermedia. The idea here is links inside >> content. I don't see how SOAP cannot send links in its content which is >> also XML. With SOAP, the links is not universally defined like the <a> >> tag in HTML. However, the idea here is not about how to define the tag, >> but way to link from one point to another. > > It is not just about links inside content. It's about the fact that > each resource is a first-class Web resource with its own URL, and it > can be linked to, retrieved, cached, etc. > >> So, there you go. If you don't know REST, you can check the link on top >> (or other resource). Read my comment (optional of course) and get your >> own opinion on it. To me, it's just a catch phrase. However, its use >> maybe important and widespread. The point is that if I coin WEB as >> "ASDF", then "ASDF" is as important and and widespread, but what >> significance is in the new name? > > I suggest you take another look and try to think outside the box this > time. REST is fundamentally different. > > Anne > >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
