My question is about Representational State Transfer (REST).
It is widely used in web services.
I have learnt that it comes from a PhD thesis from Th. R. Fielding, “Architectural Styles and the Design of Network-based Software Architectures”.
Where else is it used? Any concrete examples other than web?
The whole point of the REST thesis is to describe a set of design principles for building services on top of HTTP. I’m sure you could find things built on other protocols that share similarities to REST’s goals, but that’s not really what it’s about.
In my professor’s slides it says that “REST can also be used to realize Web Services”. The keyword here is “also”. It makes me wonder what other services use REST other than web services. Maybe, there are other type of software systems that utilize REST and is not widely know. I’d like to learn if such systems exist.
Well, this is getting into a bit of semantics.
The original REST paper describes a set of abstract principles for realizing services. The goal of the paper was describing design principles that could be realized with the current technology that was already being used at the time - namely HTTP/1.1. So you can talk about REST principles in an abstract sense of service design, or you can talk about actually building real things with REST and HTTP. Or you could talk about other things that are REST-like and maybe don’t involve HTTP.
I’m not sure what you mean by “web service”?
REST is a quasi-standard for sharing and consuming data using the HTTP protocol.
If you mean “web service” in the sense of a service accessible over the public internet then, yes, there are uses for REST outside of that. Specifically, they could be used for services that are only accessible on an intranet or even only accessible within a single host to applications also running on that host.
If you mean “web service” in the sense of a service which is responsive to the HTTP protocol then, no, there’s no way to use REST except as a web service since REST is specifically a standard implemented on top of HTTP.
There are some other concepts with parallels to REST, for example object databases and queries which denote a path through the structures from the root, and there’s also CRUD, but those aren’t REST.
The original REST dissertation certainly talks about the concepts in a sufficiently abstract way that it could be applied to protocols other than HTTP (which is probably what prompted the OP). But it also very clearly has the web interactions in mind, and I can’t think of any other example of its implementation.
I myself would tend to call any software that implemented a REST interface necessarily a Web service (but not the other way around, a SOAP Web service is not a REST Web service).
But there is a bit of an opposite view in the documantation for the RESTeasy framework:
So you could build something called a “RESTful Java application” that has a REST interface but is not a Web service.
What I think they mean is using a REST protocol as a private RPC mechanism (maybe even just a local RPC mechanism) inside of a Java application.
One distinguishing characteristic could be e.g. whether you go through the trouble of making a WSDL description for the service.
I’m not clear on what you seem to be saying a “RESTful Java application” is here if not a web service.
Well I myself would tend to agree that a “RESTful Java application” is a Web service. Just tried to explain that bit of RESTeasy doc as an opposite interpretation. YMMV
Wouldn’t the best thing here be for you to ask your professor what else REST can be used for? After all, he’s the one who used the word also.
What he might be getting at is that you can follow the REST approach to build an entire system (client and server, all operations, navigation, etc.), or, as most people do, you can just use a REST-like kind of approach when building web services/api’s while not really adhering to the rest of REST (e.g. not using “Hypermedia as the engine of application state”).
Yes but he doesn’t answer. :mad:
I really think he was getting at the idea that there is a full set of ideas around REST that can drive the approach to the entire system. A webservice is just an api, which is just one portion of the set of ideas.
A Web service is commonly seen as a software program that listens for incoming messages from “another” program.
But you can use REST also as an RPC protocol among components within the “same” program.
Is such a REST interface not a Web service?
That’s what I think that aforementioned RESTeasy document is saying.
Specifically, you can use the RESTeasy framework in much the same manner as the Microsoft COM framework, where you construct “one program” out of multiple COM objects.
In particular, you can have “in-process” REST annotated objects. Those are not Web services.
Then you can turn those into “out-of-process” REST objects. I wouldn’t say Microsoft out-of-process COM servers are Web services. By analogy such REST objects aren’t “meant” to be Web services.
Here’s another reference:
The Wiki page on Web Services at one point mentions a contrast between “Representational state transfer (REST) versus remote procedure call (RPC)”. A RESTeasy “RESTful Java Application” would be using a REST protocol for Remote Procedure Call, not Representational State Transfer. Hence not a Web Service.
Just trying to play devil’s advocate. Not saying I would see it that way.
This.