Hello. In this module,
we'll cover the fundamentals of RESTful API Design so that you can
build APIs that are easy to understand for app developers.
Roy Fielding in his PhD thesis coined the term REST or "Representational State Transfer",
which is an architectural style for distributed information systems.
REST has a set of constraints,
and one of which is HATEOAS or Hypermedia as the Engine of Application State,
which means that response payloads should include hyperlinks
instructing the developer application on what action can be performed next.
This module will focus on Pragmatic REST,
which is an outside in-view of how to design
an API and may not include hyperlinks in the response payloads.
We'll use the standard HTTP semantics
and define representations that are easy to understand,
self-documented and allows your app developers to consume the API as quickly as possible.
If you think about REST on a scale of zero to three,
REST is the highest level,
level three, and Pragmatic REST is the second level.
Pragmatic REST utilizes the standard HTTP Verbs,
and the action of the verb is performed on the resource.
If you use the above concepts,
your API will be understood by anyone that understands REST.
Some of the benefits of Pragmatic REST are that it's easier to implement over
pure REST and it provides clear intent on how to consume your API.
Let's review some examples.
In this example, a GET Operation is performed on the V1 customers resource.
This request returns an array of customers.
In this example, a GET Operation is performed on
the customer's resource and the customer ID is also included in the URI.
This request returns a single customer and the response payload.
In this example, a request is being made to a deprecated version of the customer API.
Instead of an error, the response should display a message
instructing the consumer what action to take next.
In this case, the recommended approach is to return a response with
useful information and return HTTP status of 301,
moved permanently, and include the correct URL in
the location header so that the consumers can handle the redirect accordingly.
In this last example,
the client sent an If-Modified-Since header with the request to instruct
the server to send the response only if it was updated after the date in this header.
If the resource is not modified,
then a HTTP status of 304 Not Modified is returned.
In this case, the client can use the cached resource.
For more information on this topic,
refer to the links in the video description.
And if you have any questions,
please post them on the community.