I am curious whether HATEOAS is the skeleton of REST. If it is, is HATEOAS a CRUD-based model or not? If not, what is the difference?
I find applications that create CRUD applications from HATEOAS. Is that enough evidence to say HATEOAS is based on CRUD?
i am curious if hateoas is the skeleton of rest
Yes, see Fielding 2008: REST APIs must be hypertext driven.
hateoas is a crud based model or not ?
Not necessarily, no. In the case of the web, the primary hypermedia controls are links and forms. Forms are used to send representations to the origin server, but the semantics of a form submission are not necessarily create/update/delete.
Related
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
In an effort to grasp the underlying purpose of a RESTful API, I've begun delving into HATEOAS.
According to that wikipedia page,
A REST client needs no prior knowledge about how to interact with any particular application or server beyond a generic understanding of hypermedia. By contrast, in a service-oriented architecture (SOA), clients and servers interact through a fixed interface shared through documentation or an interface description language (IDL).
Now, I don't really understand how that's supposed to work, unless there exists prior knowledge of what is available in an API, which decries the stated purpose of HATEOAS. In fact, tools such as Swagger exist for the express purpose of documenting RESTful APIs.
So while I understand that HATEOAS can allow a webservice to indicate the state of a resource, I am missing the link (haha) demonstrating how a client application could possibly figure out what to do with the returned follow-up links in the absence of some sort of "fixed interface".
How is HATEOAS supposed to accomplish this?
You're confusing things. Tools like Swagger don't exist for the express purpose of documenting RESTful APIs. They exist for the express purpose of documenting HTTP APIs that aren't RESTful! You need tools like that for APIs that are not hypertext driven and focus documentation on URI semantics and methods instead of media-types. All those fancy tools that generate lists of URIs and HTTP methods are exactly the opposite of what you are supposed to do in REST. To quote Roy Fielding on this matter:
A REST API should spend almost all of its descriptive effort in
defining the media type(s) used for representing resources and driving
application state, or in defining extended relation names and/or
hypertext-enabled mark-up for existing standard media types. Any
effort spent describing what methods to use on what URIs of interest
should be entirely defined within the scope of the processing rules
for a media type (and, in most cases, already defined by existing
media types). [Failure here implies that out-of-band information is
driving interaction instead of hypertext.]
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
HATEOAS doesn't preclude the need for all documentation. HATEOAS allows you to focus your documentation on your media-types. Your application is supposed to conform to the underlying protocol -- HTTP, most of the time -- and the authoritative documentation on that protocol is all your clients should need for driving the interaction. But they still need to know what they are interacting with.
For instance, when you enter Stack Overflow, you know there are users, questions and answers. You need documentation on what exactly are those things, but you don't need documentation detailing what a click on a link or a button does. Your browser already knows how to drive that, and that's how it works everywhere else.
To quote another answer, REST is the architectural style of the web itself. When you enter Stack Overflow, you know what an User, a Question and an Answer are, you know the media types, and the website provides you with the links to them. A REST API has to do the same. If we designed the web the way people think REST should be done, instead of having a home page with links to Questions and Answers, we'd have a static documentation explaining that in order to view a question, you have to take the URI stackoverflow.com/questions/, replace id with the Question.id and paste that on your browser. That's nonsense, but that's what many people think REST is.
There are various answers to this question depending on the level of autonomy of the client interacting with the service ...
Lets first look at a human driven client - the browser. The browser knows nothing about banks, concerts, cats and whatever else you find on the net - but it certainly knows how to render HTML. HTML is a media type with support for hypermedia (links and forms). In this case you have a perfectly working application with a client that only understands generic hypermedia. The "fixed interface" here is HTML.
Then we have the autonomous clients or "scripted" clients that are supposed to interact with a service without human interaction. This is probably the kind of client you are thinking of when comparing REST to SOA(P). You could find such clients in integration scenarios where two independent computer system exchange data in some predefined way.
Such autonomous clients must certainly agree on something in order to interact with each other. The question is what this "something" is or is not.
In a service oriented architecture the clients agree on specific URLs/endpoints and specific "methods" to invoke on those endpoints (RPC) - this adds coupling on the URL structure used. It also forces the client to know which method to call on what service - the server cannot change URLs and it cannot move a "method" from one service to another without breaking clients.
REST/hypermedia based systems behaves differently. In such a system the client and server agrees on one common entry URL where the client can lookup (GET) a service document, at runtime, describing all the possible interactions with the server using hypermedia controls such as links or forms. These hypermedia controls informs the client about how to interact with the service (the HTTP method and payload encoding) and where to interact with the service. Which in essence means we do not have "a service" anymore but possibly many different services as the client will be told, at runtime, where and how to interact with them.
So how does the client know which hypermedia controls it should look for? It does so by agreeing on a set of identifiers the server will use to identify the relevant controls. For links this is often referred to as "link relation types".
This leads us to what kind of "something" it is that servers and clients agree on - it is 1) a hypermedia enabled media type, 2) the root service index URL, 3) the hypermedia control identifiers and 4) the payload expected for each of the controls. At runtime the client then discovers the remaining URLs, HTTP methods and payload encoding (such as JSON, XML or URL-encoded key/value pairs).
Currently there are a small set of general purpose media types for hypermedia APIs - Mason, HAL, Sirene, Collection JSON, Hydra for JSON-LD and probably a few more.
If your are interested then I have covered this topic in various blog postings:
The role of media types in RESTful web services
Media types for APIs
Selling the benefits of hypermedia in APIs
Hypermedia API documentation example
RESTful resources are not typed
What is basic difference between restful and restless, i've been reading a few articles people seem to use them interchangeably.
REST stands for REpresentational State Transfer and goes a little something like this:
We have a bunch of uniquely addressable 'entities' that we want made available via a web application. Those entities each have some identifier and can be accessed in various formats. REST defines a bunch of stuff about what GET, POST, etc mean for these purposes.
the basic idea with REST is that you can attach a bunch of 'renderers' to different entities so that they can be available in different formats easily using the same HTTP verbs and url formats.
For more clarification on what RESTful means and how it is used google rails. Rails is a RESTful framework so there's loads of good information available in its docs and associated blog posts. Worth a read even if you arent keen to use the framework. For example: http://www.sitepoint.com/restful-rails-part-i/
RESTless means not restful. If you have a web app that does not adhere to RESTful principles then it is not RESTful
'RESTless' is a term not often used.
You can define 'RESTless' as any system that is not RESTful. For that it is enough to not have one characteristic that is required for a RESTful system.
Most systems are RESTless by this definition because they don't implement HATEOAS.
Any model which don't identify resource and the action associated with is restless. restless is not any term but a slang term to represent all other services that doesn't abide with the above definition. In restful model resource is identified by URL (NOUN) and the actions(VERBS) by the predefined methods in HTTP protocols i.e. GET, POST, PUT, DELETE etc.
Here are roughly summarized the key differences between RESTful and RESTless web services (it does not have to be strictly valid):
1. Protocol
RESTful services use REST architectural style,
RESTless services use SOAP protocol.
2. Business logic / Functionality
RESTful services use URL to expose business logic,
RESTless services use the service interface to expose business logic.
3. Security
RESTful inherits security from the underlying transport protocols,
RESTless defines its own security layer, thus it is considered as more secure.
4. Data format
RESTful supports various data formats such as HTML, JSON, text, etc,
RESTless supports XML format.
5. Flexibility
RESTful is easier and flexible,
RESTless is not as easy and flexible.
6. Bandwidth
RESTful services consume less bandwidth and resource,
RESTless services consume more bandwidth and resources.