Book Image

Hands-On RESTful Web Services with TypeScript 3

By : Biharck Muniz Araújo
5 (1)
Book Image

Hands-On RESTful Web Services with TypeScript 3

5 (1)
By: Biharck Muniz Araújo

Overview of this book

In the world of web development, leveraging data is the key to developing comprehensive applications, and RESTful APIs help you to achieve this systematically. This book will guide you in designing and developing web services with the power of TypeScript 3 and Node.js. You'll design REST APIs using best practices for request handling, validation, authentication, and authorization. You'll also understand how to enhance the capabilities of your APIs with ODMs, databases, models and views, as well as asynchronous callbacks. This book will guide you in securing your environment by testing your services and initiating test automation with different testing approaches. Furthermore, you'll get to grips with developing secure, testable, and more efficient code, and be able to scale and deploy TypeScript 3 and Node.js-powered RESTful APIs on cloud platforms such as the Google Cloud Platform. Finally, the book will help you explore microservices and give you an overview of what GraphQL can allow you to do. By the end of this book, you will be able to use RESTful web services to create your APIs for mobile and web apps and other platforms.
Table of Contents (20 chapters)
Free Chapter
Section 1: Unraveling API Design
Section 2: Developing RESTful Web Services
Section 3: Enhancing RESTful Web Services
Section 4: Extending the Capabilities of RESTful Web Services

REST architectural styles

The REST architectural style describes six constraints. These constraints were originally described by Roy Fielding in his Ph.D. thesis ( They include the following:

  • Uniform interface
  • Stateless
  • Cacheable
  • Client-server architecture
  • A layered system
  • Code on demand (optional)

We will discuss them all minutely in the following subsections.

Uniform interface

Uniform interface is a constraint that describes a contract between clients and servers. One of the reasons to create an interface between them is to allow each part to evolve regardless of each other. Once there is a contract aligned with the client and server parts, they can start their works independently because, at the end of the day, the way that they will communicate is firmly based on the interface:

The uniform interface is divided into four main groups, called principles:

  • Resource-based
  • The manipulation of resources using representations
  • Self-descriptive messages
  • Hypermedia as the Engine of Application State (HATEOAS)

Let's talk more about them.


One of the key things when a resource is being modeled is the URI definition. The URI is what defines a resource as unique. This representation is what will be returned for clients. If you decided to perform GET to the offer URI, the resource that returns should be a resource representing an order containing the ID order, creation date, and so on. The representation should be in JSON or XML.

Here is a JSON example:

id : 1234,
creation-date : "1937-01-01T12:00:27.87+00:20",

Here is an XML example:


The manipulation of resources using representations

Following the happy path, when the client makes a request to the server, the server responds with a resource that represents the current state of its resource. This resource can be manipulated by the client. The client can request what kind it desires for the representation such as JSON, XML, or plain text.

When the client needs to specify the representation, the HTTP Accept header is used.

Here you can see an example in plain text:

GET https://<HOST>/orders/12345
Accept: text/plain

The next one is in JSON format:

GET https://<HOST>/orders/12345
Accept: application/json

Self-descriptive messages

In general, the information provided by the RESTful service contains all the information about the resource that the client should be aware of. There is also a possibility of including more information than the resource itself. This information can be included as a link. In HTTP, it is used as the content-type header and the agreement needs to be bilateral—that is, the requestor needs to state the media type that it's waiting for and the receiver must agree about what the media type refers to.

Some examples of media types are listed in the following table:

Extension Document Type MIME type


AAC audio file



Archive document



Audio Video Interleave (AVI)



Cascading Style Sheets (CSS)



Comma-separated values (CSV)



Microsoft Word



Electronic publication (EPUB)



Graphics Interchange Format (GIF)



HyperText Markup Language (HTML)



Icon format



iCalendar format



Java Archive (JAR)



JPEG images



JavaScript (ECMAScript)



JSON format



MPEG video



Apple Installer Package



OpenDocument text document



OGG audio



OGG video






OpenType font



Portable Network Graphics



Adobe Portable Document Format (PDF)



Microsoft PowerPoint



RAR archive



Rich Text Format (RTF)



Bourne shell script



Scalable Vector Graphics (SVG)



Tape Archive (TAR)



TypeScript file



TrueType Font



Microsoft Visio



Waveform Audio Format



ZIP archive



7-zip archive


There is also a possibility of creating custom media types. A complete list can be found at


HATEOAS is a way that the client can interact with the response by navigating within it through the hierarchy in order to get complementary information.

For example, here the client makes a GET call to the order URI :

GET https://<HOST>/orders/1234

The response comes with a navigation link to the items within the 1234 order, as in the following code block:

id : 1234,
links": [
"href": "1234/items",
"rel": "items",
"type" : "GET"

What happens here is that the link fields allow the client to navigate until 1234/items in order to see all the items that belong to the 1234 order.


Essentially, stateless means that the necessary state during the request is contained within the request and it is not persisted in any hypothesis that could be recovered further. Basically, the URI is the unique identifier to the destination and the body contains the state or changeable state, or the resource. In other words, after the server handles the request, the state could change and it will send back to the requestor with the appropriate HTTP status code:

In comparison to the default session scope found in a lot of existing systems, the REST client must be the one that is responsible in providing all necessary information to the server, considering that the server should be idempotent.

Stateless allows high scalability since the server will not maintain sessions. Another interesting point to note is that the load balancer does not care about sessions at all in stateless systems.

In other words, the client needs to always pass the whole request in order to get the resource because the server is not allowed to hold any previous request state.


The aim of caching is to never have to generate the same response more than once. The key benefits of using this strategy are an increase in speed and a reduction in server processing.

Essentially, the request flows through a cache or a series of caches, such as local caching, proxy caching, or reverse proxy caching, in front of the service hosting the resource. If any of them match with any criteria during the request (for example, the timestamp or client ID), the data is returned based on the cache layer, and if the caches cannot satisfy the request, the request goes to the server:

Client-server architecture

The REST style separates clients from a server. In short, whenever it is necessary to replace either the server or client side, things should flow naturally since there is no coupling between them. The client side should not care about data storage and the server side should not care about the interface at all:

A layered system

Each layer must work independently and interact only with the layers directly connected to it. This strategy allows passing the request without bypassing other layers. For instance, when scaling a service is desired, you might use a proxy working as a load balancer—that way, the incoming requests are deliverable to the appropriate server instance. That being the case, the client side does not need to understand how the server is going to work; it just makes requests to the same URI.

The cache is another example that behaves in another layer, and the client does not need to understand how it works either:

Code on demand

In summary, this optional pattern allows the client to download and execute code from the server on the client side. The constraint says that this strategy improves scalability since the code can execute independently of the server on the client side: