• 29 Jan 18
  

  Technical analysis is hard work. Following the crowd is easy, but it's often a shortcut to the wrong place.
  

  toread

• 30 Mar 17
  

  Rodolfo Arce

  rest web architecture restful api

• 21 Feb 17
  

  blittle
  • set of constraints
  • separating the user interface concerns from the data storage concerns, we improve the portability of the user interface across multiple platforms and improve scalability by simplifying the server components
  • separation allows the components to evolve independently
  • each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server
  • communication must be stateless in nature
  • This constraint induces the properties of visibility, reliability, and scalability
  • The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components (

  5 more annotations...

• 11 Nov 16
  

  Bart Du Bois

  rest architecture

  • introduces and elaborates the Representational State Transfer (REST) architectural style for distributed hypermedia systems, describing the software engineering principles guiding REST and the interaction constraints chosen to retain those principles,
  • Separation of concerns is the principle behind the client-server constraints
  • improve the portability of the user interface across multiple platforms and improve scalability by simplifying the server components.
  • allows the components to evolve independently
  • an architectural style consisting of the set of constraints
  • communication must be stateless in nature
  • each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client
  • Visibility is improved because a monitoring system does not have to look beyond a single request datum
  • two common perspectives on the process of architectural design
  • Reliability is improved because it eases the task of recovering from partial failures
  • Scalability is improved because not having to store state between requests allows the server component to quickly free resources
  • simplifies implementation because the server doesn't have to manage resource usage across requests
  • The first is that a designer starts with nothing--a blank slate, whiteboard, or drawing board--and builds-up an architecture from familiar components until it satisfies the needs of the intended system
  • disadvantage is that it may decrease network performance by increasing the repetitive data (per-interaction overhead) sent in a series of requests, since that data cannot be left on the server in a shared context
  • The second is that a designer starts with the system needs as a whole, without constraints, and then incrementally identifies and applies constraints to elements of the system in order to differentiate the design space and allow the forces that influence system behavior to flow naturally, in harmony with the system.
  • data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable
  • add cache constraints to form the client-cache-stateless-server style
  • potential to partially or completely eliminate some interactions, improving efficiency, scalability, and user-perceived performance by reducing the average latency of a series of interactions
  • a cache can decrease reliability if stale data within the cache differs significantly
  • emphasis on a uniform interface between components
  • Implementations are decoupled from the services they provide, which encourages independent evolvability
  • overall system architecture is simplified and the visibility of interactions is improved

  20 more annotations...

• 10 Jun 16
  

  deetromp

  rest web architecture webservices design fielding

• 10 Feb 16
  

  cbddsultan

  • CHAPTER 5

     

    Representational State Transfer (REST)
• 26 Oct 15
  

  danieleandreis

  rest web architecture design programming

• 16 Sep 15
  

  J. Felix Ontañón

  api rest reference unidad9

• 25 May 15
  

  Alexey Tarasevich

  REST

  • The second is that a designer starts with the system needs as a whole, without constraints, and then incrementally identifies and applies constraints to elements of the system in order to differentiate the design space and allow the forces that influence system behavior to flow naturally, in harmony with the system.
  • emphasizes restraint and understanding of the system context.
  • information is transferred in a standardized form rather than one which is specific to an application's needs.
  • 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.
  • REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts.
  • 2) encapsulate the data with a rendering engine and send both to the recipient;
  • 1) render the data where it is located and send a fixed-format image to the recipient;
  • 3) send the raw data to the recipient along with metadata that describes the data type, so that the recipient can choose their own rendering engine.

  6 more annotations...

• 26 Feb 15
  

  tareq124
  • Table 5-1: REST Data Elements  Data Element Modern Web Examples  resource the intended conceptual target of a hypertext reference  resource identifier URL, URN  representation HTML document, JPEG image  representation metadata media type, last-modified time  resource metadata source link, alternates, vary  control data if-modified-since, cache-control
  • The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author's hypertext reference must fit within the definition of a resource. A resource is a conceptual mapping to a set of entities
  • REST uses a resource identifier to identify the particular resource involved in an interaction between components. REST connectors provide a generic interface for accessing and manipulating the value set of a resource, regardless of how the membership function is defined or the type of software that is handling the request. The naming authority that assigned the resource identifier, making it possible to reference the resource, is responsible for maintaining the semantic validity of the mapping over time (i.e., ensuring that the membership function does not change).
  • REST components perform actions on a resource by using a representation to capture the current or intended state of that resource and transferring that representation between components. A representation is a sequence of bytes, plus representation metadata to describe those bytes. Other commonly used but less precise names for a representation include: document, file, and HTTP message entity, instance, or variant.
  • A representation consists of data, metadata describing the data, and, on occasion, metadata to describe the metadata (usually for the purpose of verifying message integrity). Metadata is in the form of name-value pairs, where the name corresponds to a standard that defines the value's structure and semantics. Response messages may include both representation metadata and resource metadata: information about the resource that is not specific to the supplied representation.
  • All REST interactions are stateless. That is, each request contains all of the information necessary for a connector to understand the request, independent of any requests that may have preceded it. This restriction accomplishes four functions: 1) it removes any need for the connectors to retain application state between requests, thus reducing consumption of physical resources and improving scalability; 2) it allows interactions to be processed in parallel without requiring that the processing mechanism understand the interaction semantics; 3) it allows an intermediary to view and understand a request in isolation, which may be necessary when services are dynamically rearranged; and, 4) it forces all of the information that might factor into the reusability of a cached response to be present in each request.
  •                

    Table 5-3: REST Components

    Component	Modern Web Examples
    origin server	Apache httpd, Microsoft IIS
    gateway	Squid, CGI, Reverse Proxy
    proxy	CERN Proxy, Netscape Proxy, Gauntlet
    user agent	Netscape Navigator, Lynx, MOMspider
  • A user agent uses a client connector to initiate a request and becomes the ultimate recipient of the response. The most common example is a Web browser, which provides access to information services and renders service responses according to the application needs.
  • A proxy component is an intermediary selected by a client to provide interface encapsulation of other services, data translation, performance enhancement, or security protection.
  • ote that the difference between a proxy and a gateway is that a client determines when it will use a proxy.
  • gateway (a.k.a., reverse proxy) component is an intermediary imposed by the network or origin server to provide an interface encapsulation of other services, for data translation, performance enhancement, or security enforcemen

  9 more annotations...

• 20 Jan 15
  

  rogerscuall

  rest-api rest api

• 10 Jan 15
  

  jeubeda

  rest reference documentacion fundamentos webservices soa

• 09 Jan 15
  

  mohammed shannaq

  REST API

  api

• 08 Jan 15
  

  rest

• 17 Nov 14
  

  Mahmoud Naguib
• 14 Nov 14
  

  jkazda

  rest specification

• 04 Nov 14
  

  phamsyquybk
  • communication must be stateless in nature
  • request from client to server must contain all of the information necessary to understand the request,
  • The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components
  • 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.
  • render the data where it is located and send a fixed-format image to the recipient;
  • send the raw data to the recipient along with metadata that describes the data type, so that the recipient can choose their own rendering engine.
  • encapsulate the data with a rendering engine and send both to the recipient;
  • A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.

  6 more annotations...

• 02 Nov 14
  

  elf-pavlik
• 15 Sep 14
  

  rocketshooter
  • introduces and elaborates the Representational State Transfer (REST) architectural style
  • software engineering principles guiding REST
  • distributed hypermedia systems
  • contrasting them to the constraints of other architectural styles
  • interaction constraints chosen to retain those principles
  • hybrid style derived from several of the network-based architectural styles
  • combined with additional constraints that define a uniform connector interface

  5 more annotations...

• 12 Aug 14
  

  simspace

  webdev REST toread

• 08 Aug 14
  

  Perry Branch
• 25 Jul 14
  

  Russ

  code REST proposal standard dissertation web

• 25 Jun 14
  

  readme work web http rest protocol api

• 20 Jun 14
  

  W.W. Webster

  (the seminal paper)

  REST swengi algorithms

• 13 Jun 14
  

  carlos puentes

  "This chapter introduces and elaborates the Representational State Transfer (REST) architectural style for distributed hypermedia systems, describing the software engineering principles guiding REST and the interaction constraints chosen to retain those principles, while contrasting them to the constraints of other architectural styles. REST is a hybrid style derived from several of the network-based architectural styles described in Chapter 3 and combined with additional constraints that define a uniform connector interface. The software architecture framework of Chapter 1 is used to define the architectural elements of REST and examine sample process, connector, and data views of prototypical architectures."

• 23 May 14
  

  Manuel Ryan Espinosa

  Reset API Disertation

  Reset API Disertation

• 20 May 14
  

  marcotello

  rest

• 02 Apr 14
  

  Claire Collins
• 20 Mar 14
  

  rajdgreat007

  web apps state rest architecture web webservices

• 24 Dec 13
  

  Alexander Morozov

  development web architecture REST webservices design toread rating5

• 24 Nov 13
  

  Chan Mete

  REST API

• 27 Sep 13
  

  dascalb

  rest web architecture webservices programming design development fielding learn

• 18 Jul 13
  

  lfenjoy9
  • Representational State Transfer (REST)
• 07 Jun 13
  

  Mihály Nyeste

  rest

• 30 May 13
  

  Tom D

  This chapter introduces and elaborates the Representational State Transfer (REST) architectural style for distributed hypermedia systems, describing the software engineering principles guiding REST and the interaction constraints chosen to retain those principles, while contrasting them to the constraints of other architectural styles.

  architecture soa

• 14 May 13
  

  Jimmy Royer

  The dissertation on REST of Fielding that started it all.

  restful-api

• 02 May 13
  

  architecture web design development tutorial

• 16 Apr 13
  

  taboubim
  • architectural style for distributed hypermedia systems
  • REST is a hybrid style derived from several of the network-based architectural styles
• 11 Apr 13
  

  B N

  web

• 17 Mar 13
  

  tomazeli
  • The advantage of adding cache constraints is that they have the potential to partially or completely eliminate some interactions, improving efficiency, scalability, and user-perceived performance by reducing the average latency of a series of interactions. The trade-off, however, is that a cache can decrease reliability if stale data within the cache differs significantly from the data that would have been obtained had the request been sent directly to the server.
  • The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components
  • Each option has its advantages and disadvantages. Option 1, the traditional client-server style [31], allows all information about the true nature of the data to remain hidden within the sender, preventing assumptions from being made about the data structure and making client implementation easier. However, it also severely restricts the functionality of the recipient and places most of the processing load on the sender, leading to scalability problems. Option 2, the mobile object style [50], provides information hiding while enabling specialized processing of the data via its unique rendering engine, but limits the functionality of the recipient to what is anticipated within that engine and may vastly increase the amount of data transferred. Option 3 allows the sender to remain simple and scalable while minimizing the bytes transferred, but loses the advantages of information hiding and requires that both sender and recipient understand the same data types.
  • REST uses various connector types, summarized in Table 5-2, to encapsulate the activities of accessing resources and transferring resource representations. The connectors present an abstract interface for component communication, enhancing simplicity by providing a clean separation of concerns and hiding the underlying implementation of resources and communication mechanisms. The generality of the interface also enables substitutability: if the users' only access to the system is via an abstract interface, the implementation can be replaced without impacting the users. Since a connector manages network communication for a component, information can be shared across multiple interactions in order to improve efficiency and responsiveness.
  • This restriction accomplishes four functions: 1) it removes any need for the connectors to retain application state between requests, thus reducing consumption of physical resources and improving scalability; 2) it allows interactions to be processed in parallel without requiring that the processing mechanism understand the interaction semantics; 3) it allows an intermediary to view and understand a request in isolation, which may be necessary when services are dynamically rearranged; and, 4) it forces all of the information that might factor into the reusability of a cached response to be present in each request.
  • All REST interactions are stateless
  • The connector interface is similar to procedural invocation, but with important differences in the passing of parameters and results
  • consist of request control data, a resource identifier indicating the target of the request, and an optional representation
  • optional resource metadata
  • response control data
  • an optional representation
  • REST does not restrict communication to a particular protocol, but it does constrain the interface between components, and hence the scope of interaction and implementation assumptions that might otherwise be made between components.

  10 more annotations...

• 13 Mar 13
  

  Yuvaraj L

  rest restful

• 21 Jan 13
  

  markmorga

  rest web architecture webservices fielding

• 11 Oct 12
  

  olafkowalik

  REST

• 29 Aug 12
  

  Michael Kolodny
  • The design rationale behind the Web architecture can be described by an architectural style consisting of the set of constraints applied to elements within the architecture.
  • There are two common perspectives on the process of architectural design
  • The first is that a designer starts with nothing--a blank slate, whiteboard, or drawing board--and builds-up an architecture from familiar components until it satisfies the needs of the intended system
  • The second is that a designer starts with the system needs as a whole, without constraints, and then incrementally identifies and applies constraints to elements of the system in order to differentiate the design space and allow the forces that influence system behavior to flow naturally, in harmony with the system
  • Where the first emphasizes creativity and unbounded vision, the second emphasizes restraint and understanding of the system context. REST has been developed using the latter process
  • The Null style (Figure 5-1) is simply an empty set of constraints. From an architectural perspective, the null style describes a system in which there are no distinguished boundaries between components. It is the starting point for our description of REST.
  • The first constraints added to our hybrid style are those of the client-server architectural style
  • Separation of concerns is the principle behind the client-server constraints.
  • By separating the user interface concerns from the data storage concerns, we improve the portability of the user interface across multiple platforms and improve scalability by simplifying the server components
  • each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server
  • We next add a constraint to the client-server interaction
  • communication must be stateless in nature, as in the client-stateless-server (CSS) style
  • Session state is therefore kept entirely on the client
  • Visibility is improved because a monitoring system does not have to look beyond a single request datum in order to determine the full nature of the request
  • This constraint induces the properties of visibility, reliability, and scalability
  • Scalability is improved because not having to store state between requests allows the server component to quickly free resources, and further simplifies implementation because the server doesn't have to manage resource usage across requests.
  • Reliability is improved because it eases the task of recovering from partial failures
  • The disadvantage is that it may decrease network performance by increasing the repetitive data (per-interaction overhead) sent in a series of requests, since that data cannot be left on the server in a shared context
  • the application becomes dependent on the correct implementation of semantics across multiple client versions.
  • In order to improve network efficiency, we add cache constraints to form the client-cache-stateless-server style
  • Cache constraints require that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable
  • The advantage of adding cache constraints is that they have the potential to partially or completely eliminate some interactions, improving efficiency, scalability, and user-perceived performance by reducing the average latency of a series of interactions
  • The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components
  • Implementations are decoupled from the services they provide, which encourages independent evolvability
  • the overall system architecture is simplified and the visibility of interactions is improved
  • The trade-off, though, is that a uniform interface degrades efficiency, since information is transferred in a standardized form rather than one which is specific to an application's needs
  • 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
  • In order to obtain a uniform interface, multiple architectural constraints are needed to guide the behavior of components
  • In order to further improve behavior for Internet-scale requirements, we add layered system constraints
  • the layered system style allows an architecture to be composed of hierarchical layers by constraining component behavior such that each component cannot "see" beyond the immediate layer with which they are interacting
  • Layers can be used to encapsulate legacy services and to protect new services from legacy clients, simplifying components by moving infrequently used functionality to a shared intermediary
  • we place a bound on the overall system complexity and promote substrate independence
  • Intermediaries can also be used to improve system scalability by enabling load balancing of services across multiple networks and processors.
  • For a network-based system that supports cache constraints, this can be offset by the benefits of shared caching at intermediaries
  • The primary disadvantage of layered systems is that they add overhead and latency to the processing of data, reducing user-perceived performance
  • REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts
  • Allowing features to be downloaded after deployment improves system extensibility
  • However, it also reduces visibility, and thus is only an optional constraint within REST.
  • For example, if all of the client software within an organization is known to support Java applets [45], then services within that organization can be constructed such that they gain the benefit of enhanced functionality via downloadable Java classes
  • An optional constraint allows us to design an architecture that supports the desired behavior in the general case, but with the understanding that it may be disabled within some contexts.
  • REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements.
  • When a link is selected, information needs to be moved from the location where it is stored to the location where it will be used by, in most cases, a human reader.
  • 2) encapsulate the data with a rendering engine and send both to the recipient
  • three fundamental options
  • 1) render the data where it is located and send a fixed-format image to the recipient
  • 3) send the raw data to the recipient along with metadata that describes the data type, so that the recipient can choose their own rendering engine.
  • preventing assumptions from being made about the data structure and making client implementation easier
  • Option 1,
  • However, it also severely restricts the functionality of the recipient and places most of the processing load on the sender, leading to scalability problems
  • Option 2
  • provides information hiding while enabling specialized processing of the data via its unique rendering engine
  • Option 3
  • allows the sender to remain simple and scalable while minimizing the bytes transferred
  • but limits the functionality of the recipient to what is anticipated within that engine and may vastly increase the amount of data transferred
  • loses the advantages of information hiding and requires that both sender and recipient understand the same data types.
  • REST provides a hybrid of all three options by focusing on a shared understanding of data types with metadata, but limiting the scope of what is revealed to a standardized interface
  • REST components communicate by transferring a representation of a resource in a format matching one of an evolving set of standard data types
  • sending a representation that consists of instructions in the standard data format of an encapsulated rendering engine
  • REST Data Elements
  • Any information that can be named can be a resource
  • The key abstraction of information in REST is a resource
  • A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.
  • More precisely, a resource R is a temporally varying membership function M_R(t), which for time t maps to a set of entities, or values
  • A resource can map to the empty set, which allows references to be made to a concept before any realization of that concept exists
  • For example, the "authors' preferred version" of an academic paper is a mapping whose value changes over time, whereas a mapping to "the paper published in the proceedings of conference X" is static
  • First, it provides generality by encompassing many sources of information without artificially distinguishing them by type or implementation
  • This abstract definition of a resource enables key features of the Web architecture
  • Finally, it allows an author to reference the concept rather than some singular representation of that concept, thus removing the need to change all existing links whenever the representation changes
  • Second, it allows late binding of the reference to a representation, enabling content negotiation to take place based on characteristics of the request
  • REST connectors provide a generic interface for accessing and manipulating the value set of a resource
  • REST uses a resource identifier to identify the particular resource involved in an interaction between components
  • The naming authority that assigned the resource identifier, making it possible to reference the resource, is responsible for maintaining the semantic validity of the mapping over time (i.e., ensuring that the membership function does not change).
  • REST relies instead on the author choosing a resource identifier that best fits the nature of the concept being identified
  • A representation is a sequence of bytes, plus representation metadata to describe those bytes.
  • REST components perform actions on a resource by using a representation to capture the current or intended state of that resource and transferring that representation between components
  • document, file, and HTTP message entity, instance, or variant.
  • Metadata is in the form of name-value pairs, where the name corresponds to a standard that defines the value's structure and semantics
  • Control data defines the purpose of a message between components, such as the action being requested or the meaning of a response
  • Depending on the message control data, a given representation may indicate the current state of the requested resource, the desired state for the requested resource, or the value of some other resource, such as a representation of the input data within a client's query form, or a representation of some error condition for a response
  • A representation can be included in a message and processed by the recipient according to the control data of the message and the nature of the media type.
  • The data format of a representation is known as a media type
  • A data format that places the most important rendering information up front, such that the initial information can be incrementally rendered while the rest of the information is being received, results in much better user-perceived performance than a data format that must be entirely received before rendering can begin.
  • All REST interactions are stateless. That is, each request contains all of the information necessary for a connector to understand the request, independent of any requests that may have preceded it
  • 1) it removes any need for the connectors to retain application state between requests, thus reducing consumption of physical resources and improving scalability
  • 2) it allows interactions to be processed in parallel without requiring that the processing mechanism understand the interaction semantics
  • 3) it allows an intermediary to view and understand a request in isolation, which may be necessary when services are dynamically rearranged
  • 4) it forces all of the information that might factor into the reusability of a cached response to be present in each request.
  • The connector interface is similar to procedural invocation, but with important differences in the passing of parameters and results
  • The in-parameters consist of request control data, a resource identifier indicating the target of the request, and an optional representation
  • The out-parameters consist of response control data, optional resource metadata, and an optional representation
  • The primary connector types are client and server
  • A third connector type, the cache connector, can be located on the interface to a client or server connector in order to save cacheable responses to current interactions so that they can be reused for later requested interactions
  • Some cache connectors are shared, meaning that its cached responses may be used in answer to a client other than the one for which the response was originally obtained
  • By default, the response to a retrieval request is cacheable and the responses to other requests are non-cacheable.
  • If some form of user authentication is part of the request, or if the response indicates that it should not be shared, then the response is only cacheable by a non-shared cache.

  • A component can override these defaults by including control data that marks the interaction as cacheable, non-cacheable or cacheable for only a limited time.

     
  • Intermediary components act as both a client and a server in order to forward, with possible translation, requests and responses

  95 more annotations...

• 27 Aug 12
  

  Jon Huber
• 18 Jun 12
  

  gggrace14

  work design rest

  • such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.

  • This constraint induces the properties of visibility, reliability, and scalability. Visibility is improved because a monitoring system does not have to look beyond a single request datum in order to determine the full nature of the request. Reliability is improved because it eases the task of recovering from partial failures [133]. Scalability is improved because not having to store state between requests allows the server component to quickly free resources, and further simplifies implementation because the server doesn't have to manage resource usage across requests.

     
  • Like most architectural choices, the stateless constraint reflects a design trade-off. The disadvantage is that it may decrease network performance by increasing the repetitive data (per-interaction overhead) sent in a series of requests, since that data cannot be left on the server in a shared context. In addition, placing the application state on the client-side reduces the server's control over consistent application behavior, since the application becomes dependent on the correct implementation of semantics across multiple client versions.
  • Cache constraints require that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable. If a response is cacheable, then a client cache is given the right to reuse that response data for later, equivalent requests.
  • The advantage of adding cache constraints is that they have the potential to partially or completely eliminate some interactions, improving efficiency, scalability, and user-perceived performance by reducing the average latency of a series of interactions. The trade-off, however, is that a cache can decrease reliability if stale data within the cache differs significantly from the data that would have been obtained had the request been sent directly to the server.
  • mplementations are decoupled from the services they provide, which encourages independent evolvability. The trade-off, though, is that a uniform interface degrades efficiency, since information is transferred in a standardized form rather than one which is specific to an application's needs.
  • By applying the software engineering principle of generality to the component interface, the overall system architecture is simplified and the visibility of interactions is improved. Implementations are decoupled from the services they provide, which encourages independent evolvability. The trade-off, though, is that a uniform interface degrades efficiency, since information is transferred in a standardized form rather than one which is specific to an application's needs
  • 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

  • When a link is selected, information needs to be moved from the location where it is stored to the location where it will be used by, in most cases, a human reader. This is unlike many other distributed processing paradigms [6, 50], where it is possible, and usually more efficient, to move the "processing agent" (e.g., mobile code, stored procedure, search expression, etc.) to the data rather than move the data to the processor.

     
  • When a link is selected, information needs to be moved from the location where it is stored to the location where it will be used by, in most cases, a human reader. This is unlike many other distributed processing paradigms [6, 50], where it is possible, and usually more efficient
  • The Representational State Transfer (REST) style is an abstraction of the architectural elements within a distributed hypermedia system. REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements. It encompasses the fundamental constraints upon components, connectors, and data that define the basis of the Web architecture, and thus the essence of its behavior as a network-based application
  • REST components communicate by transferring a representation of a resource in a format matching one of an evolving set of standard data types, selected dynamically based on the capabilities or desires of the recipient and the nature of the resource.
  • REST therefore gains the separation of concerns of the client-server style without the server scalability problem, allows information hiding through a generic interface to enable encapsulation and evolution of services, and provides for a diverse set of functionality through downloadable feature-engines.
  • The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author's hypertext reference must fit within the definition of a resource. A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.
  • Others have a high degree of variance in their value over time
  • The only thing that is required to be static for a resource is the semantics of the mapping, since the semantics is what distinguishes one resource from another.
  • Finally, it allows an author to reference the concept rather than some singular representation of that concept, thus removing the need to change all existing links whenever the representation changes (assuming the author used the right identifier).
  • REST components perform actions on a resource by using a representation to capture the current or intended state of that resource and transferring that representation between components. A representation is a sequence of bytes, plus representation metadata to describe those bytes.
  • A representation consists of data, metadata describing the data, and, on occasion, metadata to describe the metadata (usually for the purpose of verifying message integrity). Metadata is in the form of name-value pairs, where the name corresponds to a standard that defines the value's structure and semantics.
  • The data format of a representation is known as a media type

  • A representation consists of data, metadata describing the data, and, on occasion, metadata to describe the metadata (usually for the purpose of verifying message integrity). Metadata is in the form of name-value pairs, where the name corresponds to a standard that defines the value's structure and semantics. Response messages may include both representation metadata and resource metadata: information about the resource that is not specific to the supplied representation.

     

  19 more annotations...

• 23 Apr 12
  

  beiker

  REST dev architecture

• 30 Mar 12
  

  Vivek Vijayan

  TechArticles

• 21 Mar 12
  

  Boris Raicheff

  rest official fielding

• 23 Feb 12
  

  joyita raksit

  rest web webservices architecture

• 15 Feb 12
  

  Chris Tauff

  rest web webservices programming architecture design fielding development

• 05 Feb 12
  

  Jorge Gamba

  toread rest restful learning introduction definition featured toprocess

• 01 Feb 12
  

  metabolite

  rest web webservices programming architecture design development fielding

• 26 Jan 12
  

  alexcuesta

  dissertation royfielding rest

• 24 Nov 11
  

  Chris Maloney

  Chapter 5 of Roy T. Fielding's dissertation, where he talks about REST

  rest webservices architecture roy-fielding restful-web-services dissertation

• 02 Nov 11
  

  ioygjve

  REST

• 13 Sep 11
  

  Navneet Kumar

  REST REST-API Architecture HyperMedia HyperText Papers

  • Separation of concerns is the principle behind the client-server constraints. By separating the user interface concerns from the data storage concerns, we improve the portability of the user interface across multiple platforms and improve scalability by simplifying the server components.
  • separation allows the components to evolve independently,
  • each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client
  • visibility, reliability, and scalability
  • Visibility is improved because a monitoring system does not have to look beyond a single request datum in order to determine the full nature of the request. Reliability is improved because it eases the task of recovering from partial failures [133]. Scalability is improved because not having to store state between requests allows the server component to quickly free resources
  • it may decrease network performance by increasing the repetitive data (per-interaction overhead) sent in a series of requests, since that data cannot be left on the server in a shared context. In addition, placing the application state on the client-side reduces the server's control over consistent application behavior, since the application becomes dependent on the correct implementation of semantics across multiple client versions.
  • data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable. If a response is cacheable, then a client cache is given the right to reuse that response data for later, equivalent requests.
  • they have the potential to partially or completely eliminate some interactions, improving efficiency, scalability, and user-perceived performance by reducing the average latency of a series of interactions.
  • The trade-off, however, is that a cache can decrease reliability if stale data within the cache differs significantly from the data that would have been obtained had the request been sent directly to the server.
  • a uniform interface between components
  • Implementations are decoupled from the services they provide, which encourages independent evolvability. The trade-off, though, is that a uniform interface degrades efficiency, since information is transferred in a standardized form rather than one which is specific to an application's needs.
  • 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.
  • the layered system style allows an architecture to be composed of hierarchical layers by constraining component behavior such that each component cannot "see" beyond the immediate layer with which they are interacting
  • The primary disadvantage of layered systems is that they add overhead and latency to the processing of data, reducing user-perceived performance
  • The combination of layered system and uniform interface constraints induces architectural properties similar to those of the uniform pipe-and-filter style
  • filter components selectively applied to the data stream in order to transform the content as it passes
  • it also reduces visibility, and thus is only an optional constraint within REST
  • REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements.
  • The Representational State Transfer (REST) style is an abstraction of the architectural elements within a distributed hypermedia system.
  • the nature and state of an architecture's data elements is a key aspect of REST
  • This is unlike many other distributed processing paradigms [6, 50], where it is possible, and usually more efficient, to move the "processing agent" (e.g., mobile code, stored procedure, search expression, etc.) to the data rather than move the data to the processor.
  • three fundamental options: 1) render the data where it is located and send a fixed-format image to the recipient; 2) encapsulate the data with a rendering engine and send both to the recipient; or, 3) send the raw data to the recipient along with metadata that describes the data type, so that the recipient can choose their own rendering engine.
  • the traditional client-server style [31], allows all information about the true nature of the data to remain hidden within the sender, preventing assumptions from being made about the data structure and making client implementation easier. However, it also severely restricts the functionality of the recipient and places most of the processing load on the sender, leading to scalability problems.
  • provides information hiding while enabling specialized processing of the data via its unique rendering engine, but limits the functionality of the recipient to what is anticipated within that engine and may vastly increase the amount of data transferred
  • allows the sender to remain simple and scalable while minimizing the bytes transferred, but loses the advantages of information hiding and requires that both sender and recipient understand the same data types.
  • REST provides a hybrid of all three options
  • focusing on a shared understanding of data types with metadata, but limiting the scope of what is revealed to a standardized interface.
  • REST components communicate by transferring a representation of a resource in a format matching one of an evolving set of standard data types, selected dynamically based on the capabilities or desires of the recipient and the nature of the resource.
  • The key abstraction of information in REST is a resource. Any information that can be named can be a resource
  • a resource R is a temporally varying membership function M_R(t), which for time t maps to a set of entities, or values, which are equivalent. The values in the set may be resource representations and/or resource identifiers.
  • The only thing that is required to be static for a resource is the semantics of the mapping, since the semantics is what distinguishes one resource from another.
  • First, it provides generality by encompassing many sources of information without artificially distinguishing them by type or implementation
  • late binding of the reference to a representation, enabling content negotiation to take place based on characteristics of the request.
  • it allows an author to reference the concept rather than some singular representation of that concept, thus removing the need to change all existing links whenever the representation changes
  • REST uses a resource identifier to identify the particular resource involved in an interaction between components
  • REST components perform actions on a resource by using a representation to capture the current or intended state of that resource and transferring that representation between components
  • Control data defines the purpose of a message between components, such as the action being requested or the meaning of a response.
  • A representation can be included in a message and processed by the recipient according to the control data of the message and the nature of the media type
  • The data format of a representation is known as a media type
  • connectors present an abstract interface for component communication, enhancing simplicity by providing a clean separation of concerns and hiding the underlying implementation of resources and communication mechanisms.
  • All REST interactions are stateless. That is, each request contains all of the information necessary for a connector to understand the request, independent of any requests that may have preceded it.
  • 1) it removes any need for the connectors to retain application state between requests, thus reducing consumption of physical resources and improving scalability; 2) it allows interactions to be processed in parallel without requiring that the processing mechanism understand the interaction semantics; 3) it allows an intermediary to view and understand a request in isolation, which may be necessary when services are dynamically rearranged; and, 4) it forces all of the information that might factor into the reusability of a cached response to be present in each request.
  • The in-parameters consist of request control data, a resource identifier indicating the target of the request, and an optional representation.
  • The out-parameters consist of response control data, optional resource metadata, and an optional representation
  • From an abstract viewpoint the invocation is synchronous, but both in and out-parameters can be passed as data streams. In other words, processing can be invoked before the value of the parameters is completely known, thus avoiding the latency of batch processing large data transfers.
  • The primary connector types are client and server. The essential difference between the two is that a client initiates communication by making a request, whereas a server listens for connections and responds to requests in order to supply access to its services
  • A component may include both client and server connectors.
  • A cache is typically implemented within the address space of the connector that uses it.
  • Some cache connectors are shared, meaning that its cached responses may be used in answer to a client other than the one for which the response was originally obtained. Shared caching can be effective at reducing the impact of "flash crowds" on the load of a popular server,
  • A cache is able to determine the cacheability of a response because the interface is generic rather than specific to each resource.
  • If some form of user authentication is part of the request, or if the response indicates that it should not be shared, then the response is only cacheable by a non-shared cache
  • The final form of connector type is a tunnel, which simply relays communication across a connection boundary, such as a firewall or lower-level network gateway
  • Intermediary components act as both a client and a server in order to forward, with possible translation, requests and responses.
  • REST's client-server separation of concerns simplifies component implementation, reduces the complexity of connector semantics, improves the effectiveness of performance tuning, and increases the scalability of pure server components.
  • REST enables intermediate processing by constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability.
  • REST does not restrict communication to a particular protocol, but it does constrain the interface between components

  54 more annotations...

• 26 Aug 11
  

  yasuhiro nishioka

  rest architecture web webservices programming http design reference zootool_imported

• 08 Jun 11
  

  aleot aleot

  webservices rest development design

• 18 Mar 11
  

  exhuma

  rest web development

• 

  Jimmy Vuccolo

  rest web programming webservices development design architecture

• 17 Jan 11
  

  Peter Cheung

  programming web restful

• 10 Dec 10
  

  Esfand S

  rest docs home top best theone readit

• 11 Nov 10
  

  Dan Taflin
  • the layered system style allows an architecture to be composed of hierarchical layers by constraining component behavior such that each component cannot "see" beyond the immediate layer with which they are interacting. By restricting knowledge of the system to a single layer, we place a bound on the overall system complexity and promote substrate independence.
  • All REST interactions are stateless
  • By default, the response to a retrieval request is cacheable and the responses to other requests are non-cacheable
  • Requests and responses have the appearance of a remote invocation style, but REST messages are targeted at a conceptual resource rather than an implementation identifier

  2 more annotations...

• 02 Nov 10
  

  jthorhauer
  • The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction
  • The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components
  • 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.
  • REST provides a hybrid of all three options by focusing on a shared understanding of data types with metadata, but limiting the scope of what is revealed to a standardized interface. REST components communicate by transferring a representation of a resource in a format matching one of an evolving set of standard data types, selected dynamically based on the capabilities or desires of the recipient and the nature of the resource.

  2 more annotations...

• 06 Sep 10
  

  rest

• 30 Aug 10
  

  Narendran M R

  The history and design of REST APIs

  design software computer-science

• 25 Aug 10
  

  Joe Yates

  rest

• 18 Jun 10
  

  Rafael Souza

  Web Programacao

• 14 May 10
  

  Shawn Zelinski

  Web_Development

• 08 Mar 10
  

  Jang Eui Jin

  rest architecture

• 19 Feb 10
  

  darioabdul

  rest webservices reference programming web http

• 14 Dec 09
  

  simon pasquier

  rest architecture web programming reference

• 03 Dec 09
  

  o s

  web programming reference development rest

• 28 Nov 09
  

  eimaj42jdp

  REST webservices http delicious

• 23 Oct 09
  

  andy cary

  • Client-Server

     

     The first constraints added to our hybrid style are those of the client-server architectural style (Figure 5-2), described in Section 3.4.1. Separation of concerns is the principle behind the client-server constraints. By separating the user interface concerns from the data storage concerns, we improve the portability of the user interface across multiple platforms and improve scalability by simplifying the server components. Perhaps most significant to the Web, however, is that the separation allows the components to evolve independently, thus supporting the Internet-scale requirement of multiple organizational domains.

  • Stateless

     

     We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.

  • Cache

     

     In order to improve network efficiency, we add cache constraints to form the client-cache-stateless-server style of Section 3.4.4 (Figure 5-4). Cache constraints require that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable. If a response is cacheable, then a client cache is given the right to reuse that response data for later, equivalent requests.
  • The advantage of adding cache constraints is that they have the potential to partially or completely eliminate some interactions, improving efficiency, scalability, and user-perceived performance by reducing the average latency of a series of interactions. The trade-off, however, is that a cache can decrease reliability if stale data within the cache differs significantly from the data that would have been obtained had the request been sent directly to the server.

  • Uniform Interface

     

     The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components

  • Layered System

     

     In order to further improve behavior for Internet-scale requirements, we add layered system constraints (Figure 5-7). As described in Section 3.4.2, the layered system style allows an architecture to be composed of hierarchical layers by constraining component behavior such that each component cannot "see" beyond the immediate layer with which they are interacting.
  • Intermediaries can also be used to improve system scalability by enabling load balancing of services across multiple networks and processors.
  • Placing shared caches at the boundaries of an organizational domain can result in significant performance benefits [136]. Such layers also allow security policies to be enforced on data crossing the organizational boundary, as is required by firewalls

  • Code-On-Demand

     

     The final addition to our constraint set for REST comes from the code-on-demand style of Section 3.5.3 (Figure 5-8). REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts. This simplifies clients by reducing the number of features required to be pre-implemented. Allowing features to be downloaded after deployment improves system extensibility. However, it also reduces visibility, and thus is only an optional constraint within REST.

  7 more annotations...

• 28 Sep 09
  

  Ben Dembroski

  rest web programming webservices fielding reference development

• 30 Aug 09
  

  alfred westerveld
• 14 Aug 09
  

  Marco Val

  webdev

• 02 Aug 09
  

  Виктор Накоряков

  rest architecture design reference dissertation delicious

• 27 Jul 09
  

  Ben Barth

  rest

• 23 Jul 09
  

  Philipp Heinemann

  WebApplication rest architecture web webservices programming http design

• 21 Jul 09
  

  martinchilvers

  rest web

• 

  Ben Bushoy

  rest

• 19 Jul 09
  

  maverick_blr

  rest design

• 24 May 09
  

  Leandro Rodrigo Saad Cruz

  rest

• 30 Apr 09
  

  Xavier Castaño

  REST web2.0 Article

• 15 Apr 09
  

  storni

  REST research

• 24 Mar 09
  

  Sven Duzont
• 19 Dec 08
  

  Javier Neira

  reference rest

• 16 Dec 08
  

  Satheesh Kumar Mohan

  webservices reference rest

• 29 Nov 08
  

  Geoffrey Kr

  Info on REST

  rest soap cnam probatoire

• 16 Nov 08
  

  J G

  rest architecture web-services soa

• 14 Nov 08
  

  Hamada Kazunori

  xml webservices webdev web2.0 web tutorial tech software rest

• 07 Nov 08
  

  Scott Reynolds

  rest

• 26 Oct 08
  

  Vitaliy Podoba

  web

• 22 Oct 08
  

  Tim Bunce

  Programming - APIs

• 19 Sep 08
  

  mariusz w

  rest

• 17 Sep 08
  

  dotysan

  This chapter introduces and elaborates the Representational State Transfer (REST) architectural style for distributed hypermedia systems, describing the software engineering principles guiding REST and the interaction constraints chosen to retain those pr

  REST web2.0 networking from-delicious

• 19 Aug 08
  

  Nick Gall

  REST concentrates all of the control state into the representations received in response to interactions. ... The next control state of an application resides in the representation of the first requested resource, so obtaining that first representation is

  via_delicious_20101217 hateoas REST pinboardimport20141106

Would you like to comment?

Join Diigo for a free account, or sign in if you are already a member.