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.
Related
I understand that REST is an architectural style and REST API's are HTTP requests.
So can REST only be implemented using HTTP or can we also use some others as well?
If yes any examples please.
REST is an architectural style as you mentioned. As such any architecture that conforms to its constraints implements REST in theory.
In practice implementing such a system from scratch is really complicated as it involves a lot of parts which need to conform to a lot of requirements. So I can't name you any alternatives which can be considered REST conform.
Also, if you are using URIs you are not constrained to HTTP, as URIs support a plethora of protocols. All of which should be supported by any client in which the resource identifier is a URI.
It is also important to mention, that most so called "REST APIs" do not conform to the requirements laid out by Mr. Fielding. And I don't mean in a nitpick-y way, I mean they just ignore it almost completely. Anything with OpenAPI/Swagger or just using the global application/json mediatype for example does not conform. (Here are some more easy to spot conflicts with REST)
What I mean is, I couldn't give you a good example of REST conform "API"s based on HTTP either. (Except for the good old browser-server-html stuff).
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'm not sure I understand correctly the notion of RESTful API. If I understand correctly, such an API should provide functions you can trigger with GET, POST, PUT & DELETE requests. My question is: if an API only provides POST requests functions, is it still RESTful?
You should probably watch this lecture and read this article.
REST a such has nothing to do with how much of available HTTP methods you use. So, the quick answer is: yes, it could be considered "restful" (whatever that actually means).
Buuut ... it most likely - isn't. And it has nothing to do with the abuse of POST calls.
The main indicator for this magical "RESTfulness" has nothing really to do with how you make the HTTP request (methods and pretty URLs are pointless worthless as a determining factor).
What matters is the returned data and whether, by looking at this data, you can learn about other resources and actions, that are related the resource in any given endpoint. It's basically about the discover-ability.
REST is a misused term for some time and the community especially at Stackoverflow doesn't even care about its actual intention, the decoupling of clients from server APIs in a distributed system.
Client and server achieve the decoupling by following certain recommendations like avoiding stateful connections where client state is stored at and managed by the server, using unique identifiers for resources (URIs) and further nice-to-have features like cacheability to reduce the workload both server and clients have to perform. While Fieldings dissertation lists 6 constraints, he later on explained some further rules applications following the REST architectural style have to follow and the benefits the system gains by following these. Among these are:
The API should not depend on any single communication protocol and adhere to and not violate the underlying protocol used. Altough REST is used via HTTP most of the time, it is not restricted to this protocol.
Strong focus on resources and their presentation via media-types.
Clients should not have initial knowledge or assumptions on the available resources or their returned state ("typed" resource) in an API but learn them on the fly via issued requests and analyzed responses. This gives the server the opportunity to move arround or rename resources easily without breaking a client implementation.
So, basically, if you limit yourself only to HTTP you somehow already violate the general idea REST tries to impose.
As #tereško mentioned the Richardson maturity model I want to clarify that this model is rather nonsense in the scope of REST. Even if level 3 is reached it does not mean that this architecture follows REST. And any application that hasn't reached level 3 isn't following this architectural style anyways. Note that an application that only partially follows REST isn't actually following it. It's like either properly or not at all.
In regards to RESTful (the dissertation doesn't contain this term) usually one regards a JSON based API exposed via HTTP as such.
To your actual question:
Based on this quote
... such an API should provide functions you can trigger with GET, POST, PUT & DELETE requests
in terms of REST architectural style I'd say NO as you basically use such an API for RPC calls (a relaxed probably JSON based SOAP if you will), limit yourself to HTTP only and do not use the semantics of the underlying HTTP protocol fully; if you follow the JSON based HTTP API crowd the answer is probably it depends on who you ask as there is no precise definition of the term "RESTful" IMO. I'd say no here as well if you trigger functions rather than resources on the server.
Yes. Restful has some guidelines you should follow. As long as you use HTTP verbs correctly and good practices with regards to URLs naming having only POSTs would be OK. If, on the other hand, a POST request in your application can also delete a record, then I would not call it Restful.
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 am really new to programming, and having some trouble understanding the concept of RESTful APIs. I've read about REST and RESTful APIs. I've looked through the questions already asked here in SO, but can't seem to get any better understanding of the subject.
In my network programming class I'm working with socket programming. There are two parts, part A and part B, in the task.
In part A I've programmed a server that responds to GET and POST. The server either retrieves the file asked for by the client, or writes to the file. (HTTP-protocol is used).
In part B I'm to use HTTP to implement a RESTful application. Basically it is a message server with the ability to handle GET, POST, PUT and DELETE. In this part the server is to create and interact with an xml-file. I understand how the methods work. But what I really don't understand is the following:
Why is the server in part A non-RESTful, while it is RESFTful in part B?
REST is an architectural style (not a protocol like SOAP, not a technology itself or even not an implementation, it is basically a set of a rule), This architecture offers some constraints for using HTTP. If you stick by this architectural constraints while using HTTP, it is called RESTful, otherwise, it is not-RESTful.
list of these architectural constraints here.
resource and more details wikipedia
in part A, what you wrote was just a HTTP end point. Its not a REST 'service'. Maybe you can check this link out for more explanation :
What is the difference between HTTP and REST?
Also, this link provides more info related to that - What is the advantage of using REST instead of non-REST HTTP?