I've been reading Roy Fielding dissertation, but he never defined the specific usage of the HTTP methods! who suggested to use the http verbs in the specific way we use them today in REST architecture?
he never defined the specific usage of the HTTP methods
That's right - Fielding's thesis doesn't define HTTP. It defines the motivation for the architectural constraints that guided the development of the definition of HTTP.
Put another way: the REST architectural style isn't limited to HTTP; you could use those same ideas to build something else. Of course, because HTTP is here today, and inertia is a thing, you'd need to build something a LOT better than HTTP to get everybody to adopt it.
who suggested to use the http verbs in the specific way we use them today in REST architecture?
The earliest work was, as far as I can tell, the brain child of Tim Berners-Lee in 1991. He outlined some of that history.
After that, you should really be looking to the authors of the different standards
RFC 1945
RFC 2068
RFC 2616
etc
For methods defined outside of the HTTP document set, you can look in the IANA method registry for the reference, and track down the authors from there.
GET
HEAD
POST
PUT
DELETE
are all described with RFC 1945, so credit would go to those authors, and also presumably the other members of the working group prior to May of 1996.
Related
It is often said that you should use PUT, DELETE, and other methods of HTTP 1.1 to provide a RESTful API. The purpose is to make URI to reference a resource (representation) and the method designate the action to be done. I see that HTTP 1.1 was released in 1997 and Fielding's PhD paper introducing REST took place in 2000. So, why those methods, besides GET and POST, were really added into the HTML 1.1 spec in the first place?
It would be great to have a reference on an article of something like that explaining why HTTP 1.1 method set was expanded since HTTP 1.0 without references to REST that appeared 3 years later.
HTTP/1.0 had PUT and DELETE and predated the dissertation by several years.
https://www.ietf.org/rfc/rfc1945.txt
Document is from 1996.
Aside from that, the REST dissertation was meant to describe the architecture of the web itself, not JSON apis (you didn't explicitly mention this but it's a common misconception). HTTP and HTML are an implementation of the REST architecture, even though REST was described after the first few versions HTML and HTTP.
So if you're curious if HTTP/1.1 sometimes describes things in a way that matches the REST dissertation, I think that kinda goes without saying. They had the same author, they were written around the same time and the one documentation describes the REST architecture, and the other is (part of) an implementation of the REST architecture.
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.
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).
I was thinking of how to make a RESTFul API more intention revealing. A common patter I see around various blogs on this is that conventional REST API results in
Ban a Player -> POST /players.
But I were to change to a more intention revealing interface , I could use
Ban a Player -> POST /players/{ playerid }/banPlayer
The second one I feel is more intention revealing.
The common objection I get from the team is that the second one does not comply with start REST style.
Also currently I cannot move away from a RESTful API.
I would like to hear your thoughts on this.
With Restful API design there are two schools of thought around how to apply actions to a resource.
You describe the action to be taken against the resource in the Uri:
Request Uri:
POST /players/{id}/ban
Note: Just use ban - we already know the resource is a player, its in the base Uri.
You can have the action in the body of the request:
Request Uri:
POST /players/{id}
Request Body:
{ 'action': 'ban' }
You can pick either way - whichever you prefer, there is lots of discussion on both but ultimately both are correct.
Note:
My assumption here that banning a player is more than just updating a part of it, but rather a system action (or state transition) relating to the player. Otherwise if it was just an update to the player resource you should handle with a PATCH or PUT as appropriate.
Some discussions for reference:
http://restful-api-design.readthedocs.io/en/latest/methods.html
https://github.com/interagent/http-api-design/issues/58
https://nordicapis.com/designing-a-true-rest-state-machine/
https://softwareengineering.stackexchange.com/questions/141410/restful-state-changing-actions
With plenty more if you do some Googling...
Long story short: it shouldn't be mandatory to be intention revealing but if you want to add some DDD on how this API looks like then it is nothing that prevents you from doing that
According to HATEOAS constraint of a RESTful web API (this constraint is an essential part of the "uniform interface" feature of REST, as defined in Roy Fielding's doctoral dissertation), the software clients of your API should not care about the URLs. Every possible&permitted action should be included in the response, with the corresponding link relation and URI. In this way you have to hardcode only the link relations.
This constraint does not however prevent you from making the API more intention revealing for the Human clients that try to understand the overall architecture. I recommend you to choose this path, as Human users are at least as important as the software that they write.
Roy Fielding wrote about this on his blog post.
Since you asked for the RESTful way not the best way, here's my thoughts.
Your RESTful URI options include:
/players
/players/{ playerid }/banPlayer
/player-banning
/entities?action=ban_player&method=PUT
/banana
anything else, REST doesn't dictate what your URIs should look like
The RESTful way is to expose knowledge of the next available states purely through hypertext. To do REST, you must use Hypertext As The Engine Of Application State (HATEOAS). Relying on client knowledge of the URI is depending on out-of-band knowledge, which is antithetical to REST.
Your resources do not need to map directly to your business objects. If you choose, you can represent user intent itself as a resource, e.g. a banned player event resource. You can POST to it with some info on which player to ban, and subsequent GETs will provide information on the event.
Oh and just because REST doesn't care what your URIs are, doesn't mean you shouldn't. You'll just have to use a different standard to decide what's best.
According to the REST API approaches, you need to use your entities in URI, so, as banPlayer is not an entity, you cannot use it.
I suggest to UPDATE your record with PUT method.
Here you can read more about rules. Actually, the first section about URIs is just about your case.
The common objection I get from the team is that the second one does not comply with start REST style.
The easy answer is this: consistency in the API has value, whether REST or not. So "that's not how we do it here" is going to trump "but REST says".
The spelling of URI in an API is a lot like the spelling of method names in your code. There are a lot of different arguments for different styles, but "local convention" is a strong argument by itself.
That said -- REST does not care what spelling you use for your identifiers.
This is what Fielding had to say in 2008
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.]
In band would be including the URI in the representation of the resource -- putting it into the description of a form in the HTML document. Out of band is documenting the URI, and expecting people to do the right thing with it.
Note: there's nothing wrong with human-readable URI, or documenting the URI that should be used. But notice that you can post questions to stackoverflow even though the people who wrote your browser didn't read stack overflow's API documentation -- that's REST.
This Google Cloud article API design: Understanding gRPC, OpenAPI and REST and when to use them clarifies the REST vs RPC debate. REST is more relevant for entity-centric API whereas RPC is more relevant for action-centric API (and CQRS). The most mature REST level 3 with hypermedia controls works well only for entities with simple state models.
Understand and evaluate first the benefits of REST for your case. Many APIs are REST-ish and not RESTful. OpenAPI is actually RPC mapped over and HTTP endpoints but it doesn't prevent it to be widely adopted.
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.