I am working in a RESTful application and when I was reading about REST, I found that REST is an Architectural Style and not an Architecture but I do not understand the reason. Thanks for your answer.
Sorry for my English, it is not my native language.
An architecture is prescriptive, often giving blueprints for solutions, and defining the core building blocks. For instance, "client-server" architecture defines a client, a server, and the roles those two components play.
An architectural style provides a framework for thinking about solutions - in the case of REST, the concept of resources addressable through a URL, a vocabulary for manipulating those resources, statelessness etc.
This is important, because the question "is this a client server architecture" can easily be answered - is there a client, does it connect to the server, are there clear responsibilities for each? The question "is this a RESTful solution" is much harder to answer - it requires you to see if the solution follows the mental model of REST.
REST provides guidelines for designing distributed systems, mainly "hypermedia" systems. This is based on the work of Roy Fielding. To make it clear between the "architectural style" and "architecture" you can think of the "architecture style" as a set of principles to design "concrete architectures" (or concrete implementations). In the case of REST, you can see for example that several concrete implementations were defined, for example java has developed its own implementation of the REST architectural style: JAX-RS (https://jax-rs-spec.java.net/ , https://jax-rs-spec.java.net/nonav/2.0/apidocs/index.html).
Hmm, I don't know exaxtly, but I think, it because REST describes only, that should be resources, represented by unique URLs, and actions for them, represented by HTTP-verbs and request data.
But data format, are resources objects or not - decision of developer.
Maybe, even HTTP is not necessary.
I don't know why REST is called an "architectural style". For me, REST is just a protocol for doing synchronous calls (in most cases). In the programs, you still have action based methods (like getAccount, transferAmount, createUser etc.) All these methods can be implemented using REST. Or SOAP. Or some other protocol. And all of them assume some data model.
So, in my view, REST is neither architectural style nor an architecture.
Related
Lots of websites (e.g. twitter, stackexchange) provide RESTful OPEN APIs based on the HTTP protocol. Can I design a RESTful service based on some other protocol (such as raw TCP)?
The short answer is that a RESTful service does generally imply HTTP, but it's not strictly necessary. The wikipedia entry includes a section on implementations outside the web, though it's pretty brief and really only talks about Common Management Information Protocol (CMIP).
Realistically, to most developers, RESTful services operate over HTTP.
You could surely take inspiration from RESTful protocols on the web and build your own similar protocol over raw TCP, but you may well finding yourself implementing it in the language of HTTP. At that point you may want to ask yourself why you didn't just use HTTP in the first place.
If you look at Roy Fielding's PhD thesis, you'll see that REST is defined in chapter 5, while it's applied to HTTP in chapter 6.
"Representational state transfer" is indeed quite abstract. There's no reason you couldn't apply it to your own adhoc protocol. The aim is to make it stateless, to have safe read methods (that are cacheable), and if possible idempotent write methods.
If you adhere to the true tenants of the architecture where every operation is ignorant of historical operations you could probably drum up something a bit different. Currently the easy Put, get, post and delete operations lend well to http based service calls.
Just to clarify what I mean by RESTful, it should satisfy the following constraints, taken from here:
Uniform Interface
Stateless
Cacheable
Client-Server
Layered System
Code on Demand
From my research, I believe that they aren't RESTful, primarily because :
They do not use HTTP verbs.
They do not use HTTP Response Codes.
They does not follow principles of REST connectedness which is based on HATEOAS.
Refer this resource for more information about data above conclusions are based on.
Some resources like these seem to suggest these frameworks can be used/implemented as RESTful.
Please refer to resources you're basing your answer on. This question is intended to clear the misconception about the topic strongly citing official resources.
Are RPC frameworks such as Apache Thrift or GRPC or any other RPC framework RESTful?
Taken in isolation: no.
The definitive reference on REST is Architectural Styles and
the Design of Network-based Software Architectures. Roy Fielding describes the architectural constraints that were developed while working on the web standards (RFC 1945, RFC 2068, RFC 2616, later RFC 7230).
REST is intended for long-lived network-based applications that span multiple organizations (Fielding, 2008)
"The World Wide Web" would be an example of an application built using the REST architectural style.
HTTP methods and status-codes are not themselves a REST constraint. In a REST architecture, the client and server share semantics by exchanging messages, but those aren't required to be HTTP messages. You could replace HTTP with another protocol that conforms to the architectural style, and still have a REST architecture.
Some resources like these seem to suggest these frameworks can be used/implemented as RESTful.
People who understand REST to mean HTTP+JSON are going to reach conclusions that are inconsistent with the web architecture and Fielding's thesis.
In short - HTML does a lot of the heavy lifting in making the web architectural style successful. JSON, in contrast, does not include the semantics of a "link" or a "form" that can be used to communicate to the client which transitions are possible. You need some other semantics on top of JSON to allow the server to communicate to the client which application transitions are possible; either Web Linking or a hypermedia aware dialect of JSON.
As far as can tell, you could use Thrift to create an application that satisfies the REST architectural constraints. But my guess is that it wouldn't be a particularly satisfying experience: Thrift was developed because Facebook needed a system with properties that the Web architecture didn't satisfy.
REST is great for the web. Howver, the stack composed of REST, HTTP and JSON is not optimal for high performances required for internal data transfer. Indeed, the serialization and deserialization of these protocols and formats can be prejudicial for overall speed. -- Leo Schoukroun
URI, HTTP, HTML are easily repurposed, but that flexibility comes with costs. In settings where that flexibility doesn't provide value (for instance, because you are a single organization that controls deployment of the client and the server), then more efficient formats and protocols become more interesting.
It's similar to the trade off that we've made between HTML and JSON -- JSON isn't a useful hypermedia representation; but it's perfectly satisfactory for consumption by the code on demand that has been loaded by our hypermedia representation.
Horses for courses.
REST is by definition not RPC, because the most significant distinction of REST is that it is resource oriented, which RPC is (typically) not.
Furthermore, one should refrain from trying to solve problems that are crying for RPC by inventing some "RPC over REST" solution - Programmers SE is full of these kind of questions.
In fact, such an approach would be upside down: One can implement a REST-based system by means of RPC, but the whole idea why one would want to use REST is on a completely different abstraction plane.
So I'd say the question is (sort of) a category mistake.
I know REST has, in principal, nothing to do with HTTP. HTTP is a protocol and REST is an architecture style for hypermedia transfer over the web. REST can use any application-layer protocol like HTTP, FTP etc... There are lot of discussions about REST, most of are bit confusing. e.g.; REST, non Rest.
It is stated mostly that REST puts following constraints on any application-protocol (e.g. HTTP etc). For example in Fielding's thesis.
Client-server`
Stateless
Cacheable
Layered system
Code on demand
Uniform interface
If I closely looking into RFC, the specifications of HTTP/1.1, it is stated that HTTP is Stateless, server-client, uses URIs to address resources. So these constraints about which Roy Fielding talked about are already in HTTP.
There are some API like Jersey JAX-RSwhich provide API implementation for REST based on HTTP. What extra features they add on HTTP basics? All the methods like PUT, GET are also there in HTTP.
I don't find a clear difference between HTTP and REST then if REST is implemented based on HTTP.
Clarifications:
REST is an architectural style (repeated for completeness, you seem to be clear on this point).
The World Wide Web is a reference application, which (mostly) demonstrates that architectural style.
HTTP is one of three "core" technologies in the web stack.
I don't find a clear difference between HTTP and REST then if REST is implemented based on HTTP.
The short answer is that HTTP alone is not sufficient.
Jim Webber (2011)
HTTP is an application protocol whose application domain is the transfer of documents across a network.
We had applications to transfer documents across a network prior to HTTP -- file transfer protocol, gopher, wais... all of which had negligible penetration into the general public. In contrast, the web was catastrophically successful; it was the killer app of the internet.
Fielding's thesis -- in particular Chapter 6: Experience and Evaluation -- is, among other things, an exploration of the question "why was the web so successful?" with emphasis on the architectural constraints that protected the induced properties of the web.
In 2008, Leonard Richardson introduced his maturity heuristic for evaluating web services.
[URI + HTTP + HTML] form a technology stack for web services. When people design a web service they tend to pick some technologies from the bottom of the stack. You can judge them crudely by seeing whether they pick zero, one, two, or three technologies.
When I say you pick from the stack I don't mean that you'll ever find a web service that doesn't use HTTP at all or that has no URIs. I mean there's a class of web services that doesn't really get URIs or doesn't really get HTTP. If your REST radar is finely tuned you sense there's something wrong with these services, and you can talk about violation of the RESTful constraints, but it's kind of a bloodless way to talk. It's not clear why anyone should care.
These technologies don't implement poka-yoke. Which is to say, the technologies don't force you to use them completely, correctly, or to best effect.
Ian S Robinson covered similar ground in his 2010 talk The Counterintuitive Web.
In the talk I described how we can implement rich and interesting business processes in (RESTful) Web applications, but only if we think in terms of protocol resources, not coarse-grained domain resources. By embracing the Web as first and foremost a web of data, an open set of resource representations manipulated in the same-old-same-old ways using a closed set of verbs, our designs capture the behaviours most CRUD-based, data-centric applications so sorely lack.
This slide, taken from that talk, illustrates three different resource designs:
You can do all of these on HTTP, the protocol standard does not constrain you.
The design at the top of the slide has an RPC character: the business protocol is executed by sending many different messages to a single endpoint. Participation in the business protocol is limited to those components in the conversation that recognize this particular interface; in short, you can't achieve scale with out-of-the-box standard http components.
The design at the bottom has a REST character: many endpoints (resources), but the business protocol is executed by via a constrained set of messages (ie, the uniform interface) that have well specified semantics. By moving the protocol complexity from the messages to the resources, message exchange becomes business protocol agnostic -- you can achieve scale with standard components because they can participate in the exchange of representations without needing any specialization at all.
The one in the middle is Rails -- Jim Webber, 2011.
The notion of the uniform interface is critical in the success of the web; it's the constraint that allows clients (browsers, crawlers) and intermediaries (caches, reverse proxies) to develop independently of servers.
What features/constraints can be achieved with REST based API that cannot be with only HTTP based API
Fielding's thesis gives us this definition of the uniform interface:
REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.
Hypermedia is huge, but it's not HTTP -- in the web stack, hypermedia support comes from HTML. It's the highest level in Richardson's model; the technology that is most often misunderstood when implementing a web service.
As Fielding (2008) bluntly clarified, this architectural constraint is *not optional:
What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period.
A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types.... From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations.
Fundamentally, consuming a REST API is like browsing wikipedia
Specialization and innovation depend on an open set. Note the implication: the open set is potentially changing and boundless. Change is a very real thing -- for reference, see just about any discussion of API versioning. Coupling independently developed clients to an open set of resources is completely unreasonable.
But with hypertext, can use a closed set of resources (bookmarks) to provide representations to the client that direct them to today's open set of resources, and then change the bookmarked representations tomorrow when you innovate.
It's a lot of work though -- much easier in the short term to communicate the available resources to the client out of band (ie, API documentation) which allows you to use representations that don't specify hypermedia control elements (example: application/json).
REST is intended for long-lived network-based applications that span multiple organizations. If you don’t see a need for the constraints, then don’t use them.
To give "long lived" a sense of scale -- httpd was first implemented over 25 years ago, and the cutting edge of HTTP is version 2. HTML is more volatile (and somewhat older); it is all the way up to version 5 (numbering somewhat confused by the fact that WHATWG considers HTML to be a living standard).
There are some API like Jersey JAX-RS which provide API implementation for REST based on HTTP. What extra features they add on HTTP basics?
Umm... not a lot?
That's not a particularly charitable answer, and Fielding was one of the expert members, so you are invited to take my skepticism with a grain of salt.
But here's what Marc Hadley had to say in 2008
I think the API encourages a resource-centric view and makes developers think about the identifiers of their resources and the methods they support. Declarative support for content negotiation works well and the default resource life-cycle encourages a stateless approach.
Suggestion, keep "think about the identifiers of their resources" in mind as you watch Stefan Tilkov's talk REST: I don't think it means what you think it does (slides).
Here's Marc Hadley on the weaknesses of the work
If I had to identify a weakness it would have to be limited support for hypermedia as the engine of state - whilst we provide good support for extracting information from request URIs and building URIs to resources, its still very much left to the developer to use hypermedia in representations appropriately.
Yes, generation and parsing of nicely designed URI has value. However, nicely designed identifiers are not among the REST architectural constraints. Hypermedia is.
In conclusion, if you are looking to understand the distinction between HTTP and REST, JAX-RS won't help.
I have been trying to understand what a RESTful API/Web Application is supposed to look like and I cant help but wonder if the Web is already built under a RESTful architecture. Every website is basically a collection of web pages (A specific representation of the state of the Web App) and you change states by clicking links. Therefore you have Representational State Transfer!
Am I wrong in thinking this? Also, every SO answer to the question 'What is REST?' which I have managed to find fails to provide an example and show the difference between a non-RESTful API and a RESTful API.
Can someone provide that please? It would help in clearing things up. I do not want abstract terms in the answer because it would be more helpful to fit the abstract answer into an example rather than try to figure out an example from an abstract answer. Beginner speaking :)
Deepak,
in a nutshell, REST in an architectural style which helps your application make the most of the Web. The term was coined in the thesis by Roy Fielding called Architectural Styles and the Design of Network-based Software Architectures.
While a lot of REST services use HTTP and JSON, they are not limited to the aforementioned protocol and format. To tell whether a service is RESTful or not, one can use the so-called Richardson Maturity Model. The services that are not at the level three of the model are sometimes called RESTlike.
First of all, REST services are stateless, that is if you receive a huge list from the server, which is paginated, such as a list of books from the Amazon, the page you are on isn't stored at the server side, it is the responsibility of the client to inform the server about the next page's number. Also URIs are used to identify resources, e.g. each book's description can be retrieved using its unique URI, and HTTP methods such as GET and POST are used to work with resources, for instance, the former can be used to retrieve the book info and the latter to add a new book.
The crux of the style is a concept called Hypermedia As The Engine Of An Application state(HATEOAS). A simplistic explanation of what it is could be that the representations of resources (book info can be in JSON, XML, HTML etc.) should use hyperlinks to make those representations self-describing, e.g. if the book info can be edited, the link to do so should be added.
There are various proposals how to add hypermedia to representations. One possible format is Hypertext Application Language (HAL). Others include but not limited to JSON API, JSON-LD, UBER.
Personally I ventured to elaborate on the topic in my blog:
What is REST?
REST: Uniform interface
Introduction to Hypertext Application Language (HAL)
Regards, Dmitry
I thought I knew what REST/"RESTFul", restfulservices, webservices, SOA and microservices were but I came across so many different definitions that I reached the conclusion that those terms are overused, misused , or simply badly defined.
I hope to have a clear understanding of what the aforementioned terms represent, their concrete definition , their commonality and differences, advantages vs disadvantages, and most importantly the bottom line - the most important things to remember in order to use those terms appropriately.
Disclaimer: most of this post is subjective. No attempt has been made here to strictly define anything, just trying to contextualize and give a global overview of the concepts and how they relate to each other.
I thought I knew what REST/"RESTFul", restfulservices, webservices,
SOA and microservices
I'd say that all these terms fall into the umbrella of Service Oriented Architectures (SOA). Web services is a SOA using web-related technologies. REST and its subset RESTful are a set of practices to implement web services. Finally, microservices are a new set of SOA practices.
I hope to have a clear understanding of what the aforementioned terms
represent
I'll try to address this point, but using informal definitions and without entering into advantages and disadvantages. That'd be way too long and I think the biggest points should be obvious from the explanations.
SOA
I think the name is self-explanatory in this case: SOA -- which stands for Service Oriented Architecture -- refers to architectures designed with a focus on services. Now, the tricky part here is what you may or may not consider a service and that is a whole different topic.
Web services
This accounts for the subset of SOA using web-related technologies. This typically involves HTTP and XML but it could also use FTP. I think the term web here is quite vague as it generally refers to standard Internet technologies.
REST(ful)
REST is a subset of web services -- and hence a SOA -- that revolves around using HTTP for communication. There are a certain set of common practices such as a certain given relevance to URLs.
About 10 years ago when I was introduced to REST, RESTful was presented to me as a more strict REST implementation where a resource would have a unique URI and it would be managed through CRUD operations mapped to HTTP verbs -- Create = POST, Read = GET, Update = PUT, Delete = Delete.
Updating user information through a HTTP GET or POST request o a /users/1/update URL would be perfectly valid in REST, but it would not be RESTful. For the latter, the approach would be to use an HTTP PUT or PATCH over /users/1 (which would also be the URL for the rest of the operations, simply varying the HTTP verb).
I find that this distinctions has become blurred over the years. However, it still stands that RESTful is a more strict subset of REST. (The exact requirements may be debatable.)
EDIT - A more formal definition:
REST stands for Representational State Transfer and was presented by Roy Fielding in his Ph.D. thesis as an architectural style for distributed hypermedia systems. The emphasis goes into the hypermedia and self-containment decoupling the client from most beforehand knowledge among others. A website is an example: it consists on a single URI (the website root) and a media type (HTML) through which the server offers all the information a client needs regarding resources and all possible interactions.
I'd say 99% people talking about REST really mean RPC or HTTP-based interfaces: using HTTP endpoints to invoke certain actions or query data. Fielding himself has tried to clarify this. Any API formed by a set of predefined URLs expecting certain HTTP verbs and some parameters falls into that 99%. So does my description above. However, I doubt the term itself can ever survive its misuse and I think we must accept its new meaning.
Microservices
This is the more recent term; it promotes implementing applications as a set of simple independently deployable services. This contrasts with the classic approach of SOA architectures as a set of quite complex services used to build complex systems, tipically involving an enterprise service bus. However, it is important to note that although typically SOA gets associated with such systems, it is a broader term and indeed, microservices are also a subset of SOA.
Microservices usually appear hand-by-hand with modern JavaScript full-stacks -- i.e. using JavaScript for all the vertical components, from the server up to user interface. Arguably this is so because using these JavaScripts full-stacks may speed up development thanks to the simplified integration. These stacks, and hence microservices implemented using them, are usually architected through REST but from a theoretical point of view, there is nothing preventing you from using a different approach to the same philosophy.
Let me introduce you a taxonomic view of those term:
Microservices
are a subtype of services specialized by minimal responsibility.
Webservices
are a subtype of services as well, specialized by the type of service they provide wich fall under web requirements and needs.
SOA
is a subtype of architectures and hence a structural view of some components and their relationships, where happens to be services and communications between those services respectively.
rest
is a subtype of communication, underlying http protocol.
restful
is a subtype of architectures (a structural view of some components and their relationships) where specialized by relationships among components restricted to be rest communications.