Contact

Follow

©2017 by Michael Duquette. Proudly created with Wix.com

Search
  • Michael Duquette

REST not relaxing

Part of working with the LibreFoodPantry includes working with the FoodKeeper-API. So let's talk about API's, specifically REST API's. REST is an acronym that means REpresentational State Transfer. REST is a resource based, not action based, architectural style that has six design constraints. REST architectural style, data and functionality are considered resources and are accessed using Uniform Resource Identifiers (URIs). The clients and servers exchange representations of resources by using a standardized interface and protocol – typically HTTP.


BUT... REST is not HTTP!


In order to be considered a RESTful API the design must meet the first 5 of these 6 design constraints:


Client–server – The interface separates the client from the server.


Cacheable – Clients can cache responses. Responses have to, implicitly or explicitly, define themselves as cacheable, or not. This prevents clients from reusing stale or inappropriate data in response to further requests.


Uniform interface – REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and hypermedia as the engine of application state. See this article on DZone for a better understanding of HATEOAS: https://dzone.com/articles/hypermedia-driven-rest-services-with-spring-hateoa


Stateless - The necessary state to handle the request is contained within the request itself.


Layered system – 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.


Code on demand (this is the only optional constraint) – 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.


Generally, the four primary HTTP verbs used are as follows:


GET

Read a specific resource (by an identifier) or a collection of resources.


PUT

Update a specific resource (by an identifier) or a collection of resources. Can also be used to create a specific resource if the resource identifier is known before-hand.


DELETE

Remove/delete a specific resource by an identifier.


POST

Create a new resource. Also a catch-all verb for operations that don't fit into the other categories.


A little digging on the web and you will find a lot if resources concerning REST. One very helpful sight I found for getting a better understanding is https://www.restapitutorial.com


When you dig deeper into and need to use a client I recommend Insomnia (https://insomnia.rest/)


#CS@Worcester #CS448


1 view