What exactly is RESTful programming

Question

User · Answer

REST is using the various HTTP methods  mainly GET PUT DELETE  to manipulate data   Rather than using a specific URL to delete a method  say   user 123 delete   you would send a DELETE request to the  user  id  URL  to edit a user  to retrieve info on a user you send a GET request to  user  id   For example  instead a set of URLs which might look like some of the following    GET  delete user x id 123 GET  user delete GET  new user x GET  user new GET  user id 1 GET  user id 1   You use the HTTP  verbs  and have    GET  user 2 DELETE  user 2 PUT  user

User · Answer

RESTful  Representational state transfer  API programming is writing web applications in any programming language by following 5 basic software architectural style principles    Resource  data  information   Unique global identifier  all resources are unique identified by URI   Uniform interface - use simple and standard interface  HTTP   Representation - all communication is done by representation  e g  XML JSON  Stateless  every request happens in complete isolation  it s easier to cache and load-balance     In other words you re writing simple point-to-point network applications over HTTP which uses verbs such as GET  POST  PUT or DELETE by implementing RESTful architecture which proposes standardization of the interface each    resource    exposes  It is nothing that using current features of the web in a simple and effective way  highly successful  proven and distributed architecture   It is an alternative to more complex mechanisms like SOAP  CORBA and RPC    RESTful programming conforms to Web architecture design and  if properly implemented  it allows you to take the full advantage of scalable Web infrastructure

User · Answer

The answer is very simple  there is a dissertation written by Roy Fielding  1 In that dissertation he defines the REST principles  If an application fulfills all of those principles  then that is a REST application   The term RESTful was created because ppl exhausted the word REST by calling their non-REST application as REST  After that the term RESTful was exhausted as well  Nowadays we are talking about Web APIs and Hypermedia APIs  because the most of the so called REST applications did not fulfill the HATEOAS part of the uniform interface constraint   The REST constraints are the following    client-server architecture  So it does not work with for example PUB SUB sockets  it is based on REQ REP  stateless communication  So the server does not maintain the states of the clients  This means that you cannot use server a side session storage and you have to authenticate every request  Your clients possibly send basic auth headers through an encrypted connection   By large applications it is hard to maintain many sessions   usage of cache if you can  So you don t have to serve the same requests again and again  uniform interface as common contract between client and server  The contract between the client and the server is not maintained by the server  In other words the client must be decoupled from the implementation of the service  You can reach this state by using standard solutions  like the IRI  URI  standard to identify resources  the HTTP standard to exchange messages  standard MIME types to describe the body serialization format  metadata  possibly RDF vocabs  microformats  etc   to describe the semantics of different parts of the message body  To decouple the IRI structure from the client  you have to send hyperlinks to the clients in hypermedia formats like  HTML  JSON-LD  HAL  etc    So a client can use the metadata  possibly link relations  RDF vocabs  assigned to the hyperlinks to navigate the state machine of the application through the proper state transitions in order to achieve its current goal   For example when a client wants to send an order to a webshop  then it have to check the hyperlinks in the responses sent by the webshop  By checking the links it founds one described with the http   schema org OrderAction  The client know the schema org vocab  so it understands that by activating this hyperlink it will send the order  So it activates the hyperlink and sends a POST https   example com api v1 order message with the proper body  After that the service processes the message and responds with the result having the proper HTTP status header  for example 201 - created by success  To annotate messages with detailed metadata the standard solution to use an RDF format  for example JSON-LD with a REST vocab  for example Hydra and domain specific vocabs like schema org or any other linked data vocab and maybe a custom application specific vocab if needed  Now this is not easy  that s why most ppl use HAL and other simple formats which usually provide only a REST vocab  but no linked data support  build a layered system to increase scalability  The REST system is composed of hierarchical layers  Each layer contains components which use the services of components which are in the next layer below  So you can add new layers and components effortless    For example there is a client layer which contains the clients and below that there is a service layer which contains a single service  Now you can add a client side cache between them  After that you can add another service instance and a load balancer  and so on    The client code and the service code won t change  code on demand to extend client functionality  This constraint is optional  For example you can send a parser for a specific media type to the client  and so on    In order to do this you might need a standard plugin loader system in the client  or your client will be coupled to the plugin loader solution    REST constraints result a highly scalable system in where the clients are decoupled from the implementations of the services  So the clients can be reusable  general just like the browsers on the web  The clients and the services share the same standards and vocabs  so they can understand each other despite the fact that the client does not know the implementation details of the service  This makes possible to create automated clients which can find and utilize REST services to achieve their goals  In long term these clients can communicate to each other and trust each other with tasks  just like humans do  If we add learning patterns to such clients  then the result will be one or more AI using the web of machines instead of a single server park  So at the end the dream of Berners Lee  the semantic web and the artificial intelligence will be reality  So in 2030 we end up terminated by the Skynet  Until then      -

User · Answer

REST stands for Representational state transfer   It relies on a stateless  client-server  cacheable communications protocol -- and in virtually all cases  the HTTP protocol is used   REST is often used in mobile applications  social networking Web sites  mashup tools and automated business processes  The REST style emphasizes that interactions between clients and services is enhanced by having a limited number of operations  verbs   Flexibility is provided by assigning resources  nouns  their own unique universal resource indicators  URIs     Introduction about Rest

User · Answer

A REST API is an API implementation that adheres to the REST architectural constraints  It acts as an interface  The communication between the client  amp  the server happens over HTTP  A REST API takes advantage of the HTTP methodologies to establish communication between the client and the server  REST also enables servers to cache the response that improves the performance of the application  The communication between the client and the server is a stateless process  And by that  I mean every communication between the client and the server is like a new one   There is no information or memory carried over from the previous communications  So  every time a client interacts with the backend  it has to send the authentication information to it as well  This enables the backend to figure out that the client is authorized to access the data or not   With the implementation of a REST API the client gets the backend endpoints to communicate with  This entirely decouples the backend  amp  the client code

User · Answer

There is not such notion as  RESTful programming  per se  It would be better called RESTful paradigm or even better RESTful architecture  It is not a programming language  It is a paradigm   From Wikipedia      In computing  representational state transfer  REST  is an   architectural style used for web development

User · Answer

REST     HTTP analogy is not correct until you do not stress to the fact that it  MUST  be HATEOAS driven    Roy himself cleared it here   A REST API should be entered with no prior knowledge beyond the initial URI  bookmark  and set of standardized media types that are appropriate for the intended audience  i e   expected to be understood by any client that might use the API   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  The transitions may be determined  or limited by  the client   s knowledge of media types and resource communication mechanisms  both of which may be improved on-the-fly  e g   code-on-demand      Failure here implies that out-of-band information is driving interaction instead of hypertext

User · Answer

A great book on REST is REST in Practice   Must reads are Representational State Transfer  REST  and REST APIs must be hypertext-driven   See Martin Fowlers article the Richardson Maturity Model  RMM  for an explanation on what an RESTful service is      To be RESTful a Service needs to fulfill the Hypermedia as the Engine of Application State   HATEOAS   that is  it needs to reach level 3 in the RMM  read the article for details or the slides from the qcon talk      The HATEOAS constraint is an acronym   for Hypermedia as the Engine of   Application State  This principle is   the key differentiator between a REST   and most other forms of client server   system                A client of a RESTful application need   only know a single fixed URL to access   it  All future actions should be   discoverable dynamically from   hypermedia links included in the   representations of the resources that   are returned from that URL    Standardized media types are also   expected to be understood by any   client that might use a RESTful API      From Wikipedia  the free encyclopedia    REST Litmus Test for Web Frameworks is a similar maturity test for web frameworks   Approaching pure REST  Learning to love HATEOAS is a good collection of links    REST versus SOAP for the Public Cloud discusses the current levels of REST usage    REST and versioning discusses Extensibility  Versioning  Evolvability  etc   through Modifiability

User · Answer

An architectural style called REST  Representational State Transfer  advocates that web applications should use HTTP as it was originally envisioned  Lookups should use GET requests  PUT  POST  and DELETE requests should be used for mutation  creation  and deletion respectively   REST proponents tend to favor URLs  such as  http   myserver com catalog item 1729   but the REST architecture does not require these  pretty URLs   A GET request with a parameter  http   myserver com catalog item 1729   is every bit as RESTful   Keep in mind that GET requests should never be used for updating information  For example  a GET request for adding an item to a cart  http   myserver com addToCart cart 314159 amp item 1729   would not be appropriate  GET requests should be idempotent  That is  issuing a request twice should be no different from issuing it once  That s what makes the requests cacheable  An  add to cart  request is not idempotent   issuing it twice adds two copies of the item to the cart  A POST request is clearly appropriate in this context  Thus  even a RESTful web application needs its share of POST requests   This is taken from the excellent book Core JavaServer faces book by David M  Geary

User · Answer

REST defines 6 architectural constraints which make any web service     a true RESTful API    Uniform interface  Client   server  Stateless  Cacheable  Layered system Code on demand  optional    https   restfulapi net rest-architectural-constraints

User · Answer

I would say RESTful programming would be about creating systems  API  that follow the REST architectural style   I found this fantastic  short  and easy to understand tutorial about REST by Dr  M  Elkstein and quoting the essential part that would answer your question for the most part   Learn REST  A Tutorial     REST is an architecture style for designing networked applications    The idea is that  rather than using complex mechanisms such as CORBA    RPC or SOAP to connect between machines  simple HTTP is used to make   calls between machines          In many ways  the World Wide Web itself  based on HTTP  can be viewed    as a REST-based architecture          RESTful applications use HTTP requests to post data  create and or   update   read data  e g   make queries   and delete data  Thus  REST   uses HTTP for all four CRUD  Create Read Update Delete  operations    I don t think you should feel stupid for not hearing about REST outside Stack Overflow     I would be in the same situation   answers to this other SO question on Why is REST getting big now could ease some feelings

User · Answer

The point of rest is that if we agree to use a common language for basic operations  the http verbs   the infrastructure can be configured to understand them and optimize them properly  for example  by making use of caching headers to implement caching at all levels   With a properly implemented restful GET operation  it shouldn t matter if the information comes from your server s DB  your server s memcache  a CDN  a proxy s cache  your browser s cache or your browser s local storage  The fasted  most readily available up to date source can be used   Saying that Rest is just a syntactic change from using GET requests with an action parameter to using the available http verbs makes it look like it has no benefits and is purely cosmetic  The point is to use a language that can be understood and optimized by every part of the chain  If your GET operation has an action with side effects  you have to skip all HTTP caching or you ll end up with inconsistent results

User · Answer

I would say that an important building block in understanding REST lies in the endpoints or mappings  such as  customers  id  balance   You can imagine such an endpoint as being the connecting pipeline from the website  front-end  to your database server  back-end   Using them  the front-end can perform back-end operations which are defined in the corresponding methods of any REST mapping in your application

User · Answer

Here is my basic outline of REST  I tried to demonstrate the thinking behind each of the components in a RESTful architecture so that understanding the concept is more intuitive  Hopefully this helps demystify REST for some people  REST  Representational State Transfer  is a design architecture that outlines how networked resources  i e  nodes that share information  are designed and addressed  In general  a RESTful architecture makes it so that the client  the requesting machine  and the server  the responding machine  can request to read  write  and update data without the client having to know how the server operates and the server can pass it back without needing to know anything about the client  Okay  cool   but how do we do this in practice   The most obvious requirement is that there needs to be a universal language of some sort so that the server can tell the client what it is trying to do with the request and for the server to respond   But to find any given resource and then tell the client where that resource lives  there needs to be a universal way of pointing at resources  This is where Universal Resource Identifiers  URIs  come in  they are basically unique addresses to find the resources    But the REST architecture doesn   t end there  While the above fulfills the basic needs of what we want  we also want to have an architecture that supports high volume traffic since any given server usually handles responses from a number of clients  Thus  we don   t want to overwhelm the server by having it remember information about previous requests   Therefore  we impose the restriction that each request-response pair between the client and the server is independent  meaning that the server doesn   t have to remember anything about previous requests  previous states of the client-server interaction  to respond to a new request  This means that we want our interactions to be stateless   To further ease the strain on our server from redoing computations that have already been recently done for a given client  REST also allows caching  Basically  caching means to take a snapshot of the initial response provided to the client  If the client makes the same request again  the server can provide the client with the snapshot rather than redo all of the computations that were necessary to create the initial response  However  since it is a snapshot  if the snapshot has not expired--the server sets an expiration time in advance--and the response has been updated since the initial cache  i e  the request would give a different answer than the cached response   the client will not see the updates until the cache expires  or the cache is cleared  and the response is rendered from scratch again   The last thing that you   ll often here about RESTful architectures is that they are layered  We have actually already been implicitly discussing this requirement in our discussion of the interaction between the client and server  Basically  this means that each layer in our system interacts only with adjacent layers  So in our discussion  the client layer interacts with our server layer  and vice versa   but there might be other server layers that help the primary server process a request that the client does not directly communicate with  Rather  the server passes on the request as necessary    Now  if all of this sounds familiar  then great  The Hypertext Transfer Protocol  HTTP   which defines the communication protocol via the World Wide Web is an implementation of the abstract notion of RESTful architecture  or an implementation of the abstract REST class if you re an OOP fanatic like me   In this implementation of REST  the client and server interact via GET  POST  PUT  DELETE  etc   which are part of the universal language and the resources can be pointed to using URLs

User · Answer

If I had to reduce the original dissertation on REST to just 3 short sentences  I think the following captures its essence    Resources are requested via URLs  Protocols are limited to what you can communicate by using URLs  Metadata is passed as name-value pairs  post data and query string parameters     After that  it s easy to fall into debates about adaptations  coding conventions  and best practices   Interestingly  there is no mention of HTTP POST  GET  DELETE  or PUT operations in the dissertation  That must be someone s later interpretation of a  best practice  for a  uniform interface    When it comes to web services  it seems that we need some way of distinguishing WSDL and SOAP based architectures which add considerable overhead and arguably much unnecessary complexity to the interface  They also require additional frameworks and developer tools in order to implement  I m not sure if REST is the best term to distinguish between common-sense interfaces and overly engineered interfaces such as WSDL and SOAP  But we need something

User · Answer

What is REST       REST stands for Representational State Transfer   It is sometimes   spelled  ReST    It relies on a stateless  client-server  cacheable   communications protocol -- and in virtually all cases  the HTTP   protocol is used       REST is an architecture style for designing networked applications    The idea is that  rather than using complex mechanisms such as CORBA    RPC or SOAP to connect between machines  simple HTTP is used to make   calls between machines       In many ways  the World Wide Web itself  based on HTTP  can be viewed   as a REST-based architecture  RESTful applications use HTTP requests   to post data  create and or update   read data  e g   make queries     and delete data  Thus  REST uses HTTP for all four CRUD    Create Read Update Delete  operations       REST is a lightweight alternative to mechanisms like RPC  Remote   Procedure Calls  and Web Services  SOAP  WSDL  et al    Later  we will   see how much more simple REST is       Despite being simple  REST is fully-featured  there s basically   nothing you can do in Web Services that can t be done with a RESTful   architecture  REST is not a  standard   There will never be a W3C   recommendataion for REST  for example  And while there are REST   programming frameworks  working with REST is so simple that you can   often  roll your own  with standard library features in languages like   Perl  Java  or C     One of the best reference I found when I try to find the simple real meaning of rest   http   rest elkstein org

User · Answer

I apologize if I m not answering the question directly  but it s easier to understand all this with more detailed examples  Fielding is not easy to understand due to all the abstraction and terminology   There s a fairly good example here   Explaining REST and Hypertext  Spam-E the Spam Cleaning Robot  And even better  there s a clean explanation with simple examples here  the powerpoint is more comprehensive  but you can get most of it in the html version    http   www xfront com REST ppt or http   www xfront com REST html  After reading the examples  I could see why Ken is saying that REST is hypertext-driven  I m not actually sure that he s right though  because that  user 123 is a URI that points to a resource  and it s not clear to me that it s unRESTful just because the client knows about it  out-of-band    That xfront document explains the difference between REST and SOAP  and this is really helpful too  When Fielding says   That is RPC  It screams RPC    it s clear that RPC is not RESTful  so it s useful to see the exact reasons for this   SOAP is a type of RPC

User · Answer

This is very less mentioned everywhere but the Richardson s Maturity Model is one of the best methods to actually judge how Restful is one s API  More about it here   Richardson s Maturity Model

User · Answer

REST is the underlying architectural principle of the web  The amazing thing about the web is the fact that clients  browsers  and servers can interact in complex ways without the client knowing anything beforehand about the server and the resources it hosts  The key constraint is that the server and client must both agree on the media used  which in the case of the web is HTML   An API that adheres to the principles of REST does not require the client to know anything about the structure of the API  Rather  the server needs to provide whatever information the client needs to interact with the service  An HTML form is an example of this  The server specifies the location of the resource and the required fields  The browser doesn t know in advance where to submit the information  and it doesn t know in advance what information to submit  Both forms of information are entirely supplied by the server   This principle is called HATEOAS  Hypermedia As The Engine Of Application State    So  how does this apply to HTTP  and how can it be implemented in practice  HTTP is oriented around verbs and resources  The two verbs in mainstream usage are GET and POST  which I think everyone will recognize  However  the HTTP standard defines several others such as PUT and DELETE  These verbs are then applied to resources  according to the instructions provided by the server   For example  Let s imagine that we have a user database that is managed by a web service  Our service uses a custom hypermedia based on JSON  for which we assign the mimetype application json userdb  There might also be an application xml userdb and application whatever userdb - many media types may be supported   The client and the server have both been programmed to understand this format  but they don t know anything about each other  As Roy Fielding points out      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    A request for the base resource   might return something like this   Request  GET   Accept  application json userdb   Response  200 OK Content-Type  application json userdb         version    1 0        links                            href     user                rel    list                method    GET                                    href     user                rel    create                method    POST                      We know from the description of our media that we can find information about related resources from sections called  links   This is called Hypermedia controls  In this case  we can tell from such a section that we can find a user list by making another request for  user   Request  GET  user Accept  application json userdb   Response  200 OK Content-Type  application json userdb         users                            id   1               name    Emil                country   Sweden                links                                            href     user 1                        rel    self                        method    GET                                                            href     user 1                        rel    edit                        method    PUT                                                            href     user 1                        rel    delete                        method    DELETE                                                                    id   2               name    Adam                country   Scotland                links                                            href     user 2                        rel    self                        method    GET                                                            href     user 2                        rel    edit                        method    PUT                                                            href     user 2                        rel    delete                        method    DELETE                                                        links                            href     user                rel    create                method    POST                      We can tell a lot from this response  For instance  we now know we can create a new user by POSTing to  user   Request  POST  user Accept  application json userdb Content-Type  application json userdb         name    Karl        country    Austria      Response  201 Created Content-Type  application json userdb         user              id   3           name    Karl            country    Austria            links                                    href     user 3                    rel    self                    method    GET                                                href     user 3                    rel    edit                    method    PUT                                                href     user 3                    rel    delete                    method    DELETE                                      links             href     user           rel    list           method    GET            We also know that we can change existing data   Request  PUT  user 1 Accept  application json userdb Content-Type  application json userdb         name    Emil        country    Bhutan      Response  200 OK Content-Type  application json userdb         user              id   1           name    Emil            country    Bhutan            links                                    href     user 1                    rel    self                    method    GET                                                href     user 1                    rel    edit                    method    PUT                                                href     user 1                    rel    delete                    method    DELETE                                      links             href     user           rel    list           method    GET            Notice that we are using different HTTP verbs  GET  PUT  POST  DELETE etc   to manipulate these resources  and that the only knowledge we presume on the client s part is our media definition   Further reading    The many much better answers on this very page    How I explained REST to my wife    How I explained REST to my wife    Martin Fowler s thoughts PayPal s API has hypermedia controls    This answer has been the subject of a fair amount of criticism for missing the point  For the most part  that has been a fair critique  What I originally described was more in line with how REST was usually implemented a few years ago when I first wrote this  rather than its true meaning  I ve revised the answer to better represent the real meaning

User · Answer

REST is an architectural style which is based on web-standards and the HTTP protocol  introduced in 2000     In a REST based architecture  everything is a resource Users  Orders  Comments   A resource is accessed via a common interface based on the HTTP standard methods GET  PUT  PATCH  DELETE etc        In a REST based architecture you have a REST server which provides   access to the resources  A REST client can access and modify the REST   resources    Every resource should support the HTTP common operations  Resources are identified by global IDs  which are typically URIs    REST allows that resources have different representations  e g   text  XML  JSON etc  The REST client can ask for a specific representation via the HTTP protocol  content negotiation    HTTP methods   The PUT  GET  POST and DELETE methods are typical used in REST based architectures  The following table gives an explanation of these operations    GET defines a reading access of the resource without side-effects  The resource is never changed via a GET request  e g   the request has no side effects  idempotent   PUT creates a new resource  It must also be idempotent  DELETE removes the resources  The operations are idempotent  They can get repeated without leading to different results  POST updates an existing resource or creates a new resource

User · Answer

REST is a distributed systems  such as WWW  software architecture style  you can imagine that it is a well-designed Web application rules  a group of Internet Web pages  a virtual state machine   in which hyperlink by clicking link  state transition   the result is the next Web page  which means the next state of the application    REST describes the network system consists of three parts    data elements  resource  resource identifier  representation  connectors  client  server  cache  resolver  tunnel  components  origin server  gateway  proxy  user agent    REST strictly meet the following conditions    Status of the application functionality is split into resources  Each resource used as hyperlinks positioning syntax  ie  in the WWW URI  All resources share a uniform interface between the client with the resource transition state  including   A limited set of well-defined operations  ie in HTTP GET   POST   PUT   DELETE  A limited set of content format content types  which may include executable code  ie  in the WWW Javascript

User · Answer

What is API Testing   API testing utilizes programming to send calls to the API and get the yield  It testing regards the segment under test as a black box  The objective of API testing is to confirm right execution and blunder treatment of the part preceding its coordination into an application   REST API  REST  Representational State Transfer      It   s an arrangement of functions on which the testers performs requests and receive responses  In REST API interactions are made via HTTP protocol    REST also permits communication between computers with each other over a network    For sending and receiving messages  it involves using HTTP methods  and it does not require a strict message definition  unlike Web services    REST messages often accepts the form either in form of XML  or JavaScript Object Notation  JSON       4 Commonly Used API Methods -     GET      It provides read only access to a resource  POST      It is used to create or update a new resource  PUT      It is used to update or replace an existing resource or create a new resource    DELETE      It is used to remove a resource    Steps to Test API Manually -  To use API manually  we can use browser based REST API plugins      Install POSTMAN Chrome    REST Firefox  plugin Enter the API URL Select the REST method Select content-Header Enter Request JSON  POST  Click on send It will return output response   Steps to Automate REST API

User · Answer

This answer is for absolute beginners  let s know about most used API architecture today   To understand Restful programming or Restful API  First  you have to understand what API is  on a very high-level API stands for Application Programming Interface  it s basically a piece of software that can be used by another piece of software in order to allow applications to talk to each other   The most widely used type of API in the globe is web APIs while an app that sends data to a client whenever a request comes in     In fact  APIs aren t only used to send data and aren t always related to web development or javascript or python or any programming language or framework    The application in API can actually mean many different things as long as the pice of software is relatively stand-alone  Take for example  the File System or the HTTP Modules we can say that they are small pieces of software and we can use them  we can interact with them by using their API  For example when we use the read file function for a file system module of any programming language  we are actually using the file system reading API  Or when we do DOM manipulation in the browser  we re are not really using the JavaScript language itself  but rather  the DOM API that browser exposes to us  so it gives us access to it  Or even another example let s say we create a class in any programming language like Java and then add some public methods or properties to it  these methods will then be the API of each object created from that class because we are giving other pieces of software the possibility of interacting with our initial piece of software  the objects in this case  S0  API has actually a broader meaning than just building web APIs   Now let s take a look at the REST Architecture to build APIs   REST which stands for Representational State Transfer is basically a way of building web APIs in a logical way  making them easy to consume for ourselves or for others   To build Restful APIs following the REST Architecture  we just need to follow a couple of principles  1  We need to separate our API into logical resources  2  These resources should then be exposed by using resource-based URLs  3  To perform different actions on data like reading  creating  or deleting data the API should use the right HTTP methods and not the URL  4  Now the data that we actually send back to the client or that we received from the client should usually use the JSON data format  were some formatting standard applied to it  5  Finally  another important principle of EST APIs is that they must be stateless     Separate APIs into logical resources  The key abstraction of information in REST is a resource  and therefore all the data that we wanna share in the API should be divided into logical resources  What actually is a resource  Well  in the context of REST it is an object or a representation of something which has some data associated to it  For example  applications like tour-guide tours  or users  places  or revies are of the example of logical resources  So basically any information that can be named can be a resource  Just has to name  though  not a verb    Expose Structure  Now we need to expose  which means to make available  the data using some structured URLs  that the client can send a request to  For example something like this entire address is called the URL  and this   addNewTour is called and API Endpoint    Our API will have many different endpoints just like bellow  https   www tourguide com addNewTour https   www tourguide com getTour https   www tourguide com updateTour https   www tourguide com deleteTour https   www tourguide com getRoursByUser https   www tourguide com deleteToursByUser   Each of these API will send different data back to the client on also perform different actions   Now there is something very wrong with these endpoints here because they really don t follow the third rule which says that we should only use the HTTP methods in order to perform actions on data  So endpoints should only contain our resources and not the actions that we are performed on them because they will quickly become a nightmare to maintain   How should we use these HTTP methods in practice  Well let s see how these endpoints should actually look like starting with  getTour  So this getTour endpoint is to get data about a tour and so we should simply name the endpoint  tours and send the data whenever a get request is made to this endpoint  So in other words  when a client uses a GET HTTP method to access the endpoint     we only have resources in the endpoint or in the URL and no verbs because the verb is now in the HTTP method  right  The common practice to always use the resource name in the plural which is why I wrote  tours nor  tour   The convention is that when calling endpoint  tours will get back all the tours that are in a database  but if we only want the tour with one ID  let s say seven  we add that seven after another slash  tours 7  or in a search query   tours id 7   And of course  it could also be the name of a tour instead of the ID   HTTP Methods  What s really important here is how the endpoint name is the exact same name for all   GET   for requesting data from the server    https   www tourguide com tours 7 POST   for sending data to the server   https   www tourguide com tours PUT PATCH   for updating requests for data to the server   https   www tourguide com tours 7 DELETE   for deleting request for data to the server   https   www tourguide com tours 7   The difference between PUT and PATCH-  By using PUT  the client is supposed to send the entire updated object  while with PATCH it is supposed to send only the part of the object that has been changed   By using HTTP methods users can perform basic four CRUD operations  CRUD stands for Create  Read  Update  and Delete   Now there could be a situation like a bellow     So   getToursByUser can simply be translated to  users tours  for user number 3 end point will be like  users 3 tours   if we want to delete a particular tour of a particular user then the URL should be like  users 3 tours 7  here user id 3 and tour id  7   So there really are tons of possibilities of combining resources like this    Send data as JSON  Now about data that the client actually receives  or that the server receives from the client  usually we use the JSON Data Format   A typical JSON might look like below   Before sending JSON Data we usually do some simple response formatting  there are a couple of standards for this  but one of the very simple ones called Jsend  We simply create a new object  then add a status message to it in order to inform the client whether the request was a success  fail  or error  And then we put our original data into a new object called Data     Wrapping the data into an additional object like we did here is called Enveloping  and it s a common practice to mitigate some security issues and other problems   Restful API should always be stateless  Finally a RESTful API should always be stateless meaning that  in a stateless RESTful API all state is handled on the client side no on the server  And state simply refers to a piece of data in  the application that might change over time  For example  whether a certain user is logged in or on a page with a list with several pages what the current page is  Now the fact that the state should be handled on the client means that each request must contain all the information that is necessary to process a certain request on the server  So the server should never ever have to remember the previous request in order to process the current request     Let s say that currently we are on page five and we want to move forward to page six  Sow we could have a simple endpoint called  tours nextPage and submit a request to server  but the server would then have to figure out what the current page is  and based on that server will send the next page to the client  In other words  the server would have to remember the previous request  This is what exactly we want to avoid in RESTful APIs   Instead of this case  we should create a  tours page endpoint and paste the number six to it in order to request page number six  tours page 6   So the server doesn t have to remember anything in  all it has to do is to send back data for page number six as we requested    Statelessness and Statefulness which is the opposite are very important concepts in computer science and applications in general

User · Answer

What is REST   REST in official words  REST is an architectural style built on certain principles using the current    Web    fundamentals  There are 5 basic fundamentals of web which are leveraged to create REST services    Principle 1  Everything is a Resource In the REST architectural style  data and functionality are considered resources and are accessed using Uniform Resource Identifiers  URIs   typically links on the Web  Principle 2  Every Resource is Identified by a Unique Identifier  URI  Principle 3  Use Simple and Uniform Interfaces Principle 4  Communication is Done by Representation Principle 5  Be Stateless

User · Answer

This is amazingly long  discussion  and yet quite confusing to say the least   IMO   1  There is no such a thing as restful programing  without a big joint and lots of beer     2  Representational State Transfer  REST  is an architectural style specified in the dissertation of Roy Fielding  It has a number of constraints   If your Service Client respect those then it is RESTful  This is it    You can summarize significantly  the constraints to     stateless communication respect HTTP specs  if HTTP is used  clearly communicates the content formats transmitted use hypermedia as the engine of application state   There is another very good post which explains things nicely   A lot of answers copy pasted valid information mixing it and adding some confusion  People talk here about levels  about RESTFul URIs there is not such a thing    apply HTTP methods GET POST PUT     REST is not about that or not only about that   For example links - it is nice to have a beautifully looking API but at the end the client server does not really care of the links you get send it is the content that matters    In the end any RESTful client should be able to consume to any RESTful service as long as the content format is known

User · Answer

It s programming where the architecture of your system fits the REST style laid out by Roy Fielding in his thesis  Since this is the architectural style that describes the web  more or less   lots of people are interested in it   Bonus answer  No  Unless you re studying software architecture as an academic or designing web services  there s really no reason to have heard the term

User · Answer

REST is an architectural pattern and style of writing distributed applications  It is not a programming style in the narrow sense   Saying you use the REST style is similar to saying that you built a house in a particular style  for example Tudor or Victorian   Both REST as an software style and Tudor or Victorian as a home style can be defined by the qualities and constraints that make them up  For example REST must have Client Server separation where messages are self-describing  Tudor style homes have Overlapping gables and Roofs that are steeply pitched with front facing gables  You can read Roy s dissertation to learn more about the constraints and qualities that make up REST   REST unlike home styles has had a tough time being consistently and practically applied  This may have been intentional  Leaving its actual implementation up to the designer  So you are free to do what you want so as long as you meet the constraints set out in the dissertation you are creating REST Systems   Bonus   The entire web is based on REST  or REST was based on the web   Therefore as a web developer you might want aware of that although it s not necessary to write good web apps

User · Answer

I see a bunch of answers that say putting everything about user 123 at resource   user 123  is RESTful   Roy Fielding  who coined the term  says REST APIs must be hypertext-driven   In particular   A REST API must not define fixed resource names or hierarchies    So if your   user 123  path is hardcoded on the client  it s not really RESTful   A good use of HTTP  maybe  maybe not   But not RESTful   It has to come from hypertext

User · Answer

This is what it might look like   Create a user with three properties   POST  user fname John amp lname Doe amp age 25   The server responds   200 OK Location   user 123   In the future  you can then retrieve the user information   GET  user 123   The server responds   200 OK  lt fname gt John lt  fname gt  lt lname gt Doe lt  lname gt  lt age gt 25 lt  age gt    To modify the record  lname and age will remain unchanged    PATCH  user 123 fname Johnny   To update the record  and consequently lname and age will be NULL    PUT  user 123 fname Johnny

User · Answer

RESTful programming is about    resources being identified by a persistent identifier  URIs are the ubiquitous choice of identifier these days resources being manipulated using a common set of verbs  HTTP methods are the commonly seen case - the venerable Create  Retrieve  Update  Delete becomes POST  GET  PUT  and DELETE  But REST is not limited to HTTP  it is just the most commonly used transport right now   the actual representation retrieved for a resource is dependent on the request and not the identifier  use Accept headers to control whether you want XML  HTTP  or even a Java Object representing the resource maintaining the state in the object and representing the state in the representation representing the relationships between resources in the representation of the resource  the links between objects are embedded directly in the representation resource representations describe how the representation can be used and under what circumstances it should be discarded refetched in a consistent manner  usage of HTTP Cache-Control headers   The last one is probably the most important in terms of consequences and overall effectiveness of REST  Overall  most of the RESTful discussions seem to center on HTTP and its usage from a browser and what not  I understand that R  Fielding coined the term when he described the architecture and decisions that lead to HTTP  His thesis is more about the architecture and cache-ability of resources than it is about HTTP   If you are really interested in what a RESTful architecture is and why it works  read his thesis a few times and read the whole thing not just Chapter 5  Next look into why DNS works  Read about the hierarchical organization of DNS and how referrals work  Then read and consider how DNS caching works  Finally  read the HTTP specifications  RFC2616 and RFC3040 in particular  and consider how and why the caching works the way that it does  Eventually  it will just click  The final revelation for me was when I saw the similarity between DNS and HTTP  After this  understanding why SOA and Message Passing Interfaces are scalable starts to click   I think that the most important trick to understanding the architectural importance and performance implications of a RESTful and Shared Nothing architectures is to avoid getting hung up on the technology and implementation details  Concentrate on who owns resources  who is responsible for creating maintaining them  etc  Then think about the representations  protocols  and technologies

User · Answer

I think the point of restful is the separation of the statefulness into a higher layer while making use of the internet  protocol  as a stateless transport layer  Most other approaches mix things up    It s been the best practical approach to handle the fundamental changes of programming in internet era  Regarding the fundamental changes  Erik Meijer has a discussion on show here  http   www infoq com interviews erik-meijer-programming-language-design-effects-purity view 93197   He summarizes it as the five effects  and presents a solution by designing the solution into a programming language  The solution  could also be achieved in the platform or system level  regardless of the language  The restful could be seen as one of the solutions that has been very successful in the current practice    With restful style  you get and manipulate the state of the application across an unreliable internet  If it fails the current operation to get the correct and current state  it needs the zero-validation principal to help the application to continue  If it fails to manipulate the state  it usually uses multiple stages of confirmation to keep things correct  In this sense  rest is not itself a whole solution  it needs the functions in other part of the web application stack to support its working    Given this view point  the rest style is not really tied to internet or web application  It s a fundamental solution to many of the programming situations  It is not simple either  it just makes the interface really simple  and copes with other technologies amazingly well    Just my 2c    Edit  Two more important aspects     Statelessness is misleading  It is about the restful API  not the application or system  The system needs to be stateful  Restful design is about designing a stateful system based on a stateless API  Some quotes from another QA     REST  operates on resource representations  each one identified by an URL  These are typically not data objects  but complex objects abstractions   REST stands for  representational state transfer   which means it s all about communicating and modifying the state of some resource in a system   Idempotence  An often-overlooked part of REST is the idempotency of most verbs  That leads to robust systems and less interdependency of exact interpretations of the semantics

User · Answer

Edit  Read the README here and I hope you ll really get REST   https   github com lukepuplett surfdude-csharp blob master README md  --  Those answers giving examples of linked resources is great but only half the picture   So  imagine you re designing a website  You write a story   I want to be able to search for an address by postcode so that I can choose a shipping address  Then you d build the site to take the user on that journey and try and link the pages together in a workflow   A website design that took them to an address lookup but then left them to copy the address into the clipboard and then return to the shipping address form wouldn t be very useable   A REST API uses patterns we take for granted on the web for a machine-machine interaction   The search for a postcode feature shouldn t be base addresses  postcode  and a collection comes back  even if each address links to a full address and some edit links  because that s a dead end  the API consumer would need to guess how to use the address   Instead the motive for the feature should be built-in to the flow in which its used such that the journey ends back at the start   1 GET  orders 123 shipping    200 OK   Current shipping details   link to parent   link to address picker    2  - gt  GET  orders 123 shipping addresspicker        200 OK   Link and form for searching for a postcode    3   - gt  GET  orders 123 shipping addresspicker postcode tn11tl         200 OK   List of addresses each with link to pick it    4    - gt  POST  orders 123 shipping addresspicker postcode tn11tl amp pickNo 3          200 OK   Current shipping details   link to parent   link to address picker     It s a user journey and at the end you can see the impact of the flow on the order   The HTTP request response isn t strictly part of REST but I don t think anyone has ever seen a non-HTTP REST application   Now those URLs could be any set of characters  they re just identifiers  I made them pretty because they make sense to people  A machine would use the rel to work out what they do  not depend on a readable href

User · Answer

Old question  newish way of answering   There s a lot of misconception out there about this concept   I always try to remember    Structured URLs and Http Methods Verbs are not the definition of restful programming   JSON is not restful programming RESTful programming is not for APIs   I define restful programming as      An application is restful if it provides resources  being the combination of data   state transitions controls  in a media type the client understands   To be a restful programmer you must be trying to build applications that allow actors to do things   Not just exposing the database   State transition controls only make sense if the client and server agree upon a media type representation of the resource   Otherwise there s no way to know what s a control and what isn t and how to execute a control   IE if browsers didn t know  lt form gt  tags in html then there d be nothing for you to submit to transition state in your browser     I m not looking to self promote  but i expand on these ideas to great depth in my talk http   techblog bodybuilding com 2016 01 video-what-is-restful-200 html    An excerpt from my talk is about the often referred to richardson maturity model  i don t believe in the levels  you either are RESTful  level 3  or you are not  but what i like to call out about it is what each level does for you on your way to RESTful

User · Answer

To contribute with something new here  I d like to share the link of my article that Conceptualize REST through a practical and objective approach  I m covering main concepts such as   HATEOAS - Hypermedia As The Engine Of Application State  Resources and representations  Addressability  Idempotency in REST  Richardson s REST Maturity Model  Media types API Versioning  I ve created a GitHub project as well that you can run easily with docker  which covers the content that I ve presented in this article  https   itnext io how-to-build-a-restful-api-a-deep-dive-into-rest-apis-215188f80854

User · Answer

Talking is more than simply exchanging information  A Protocol is actually designed so that no talking has to occur  Each party knows what their particular job is because it is specified in the protocol  Protocols allow for pure information exchange at the expense of having any changes in the possible actions  Talking  on the other hand  allows for one party to ask what further actions can be taken from the other party  They can even ask the same question twice and get two different answers  since the State of the other party may have changed in the interim  Talking is RESTful architecture  Fielding s thesis specifies the architecture that one would have to follow if one wanted to allow machines to talk to one another rather than simply communicate

[http] What exactly is RESTful programming?

Examples related to http

Examples related to rest

Examples related to definition