Download ebooks file Building Web APIs with ASP.NET Core (MEAP Version 11) Valerio De Sanctis all chapters
Download ebooks file Building Web APIs with ASP.NET Core (MEAP Version 11) Valerio De Sanctis all chapters
com
https://ebookmeta.com/product/building-web-apis-with-asp-
net-core-meap-version-11-valerio-de-sanctis/
OR CLICK HERE
DOWLOAD NOW
manning.com
welcome
Thanks for purchasing the MEAP of ASP.NET Core Web API. I hope that
you'll like what you'll get access to! If you're looking for an efficient and
structured way to create stable, secure, and reliable Web API projects for
enterprise markets, I'm confident that you won't be disappointed by what
you've got.
Since this book is written for web developers, it takes for granted that the
reader already has some basic knowledge regarding Object-Oriented
Programming, HTTP request/response lifecycle, data-retrieval tasks, data
exchange formats such as JSON, and so on. However, no prior .NET or
ASP.NET Core knowledge is required: the main reason I've chosen to write a
book about this framework is that it is easy to learn and has a shallow
learning curve, especially if the concepts are presented clearly and with a
task-oriented, practical approach - which is precisely what I've wanted to
adopt in this book.
I sincerely hope that you'll like what I've wrote so far: please let me know
your thoughts in the liveBook Discussion forum - I can't wait to read them!
Thanks again for your interest and for purchasing the MEAP!
—Valerio De Sanctis
In this book
Almost all applications need data. This is especially true for web-based
applications, where large numbers of clients interact with a centralized entity
- typically a HTTP-based service - to access information and possibly update
or manipulate them. In this book we’ll learn how to design and develop a
specific type of HTTP-based service that has the sole purpose of providing
data to these clients, allowing them to interact with the information they
require in a uniform, structured and standardized way: a Web API.
In the first section of this chapter, we’ll see the distinctive characteristics of a
Web API and how such concept can be applied to several real-world
scenarios. In the second section we’ll familiarize with ASP.NET Core, the
web framework we’ll be using to create Web APIs throughout this book.
From that definition we can easily see how the main purpose of an API is to
allow different parties to communicate using a common syntax (or
abstraction) that simplifies and standardizes what happens under each hood.
The overall concept is not different from real-world interfaces, which also
provide a common “syntax” to allow different parties operate: a perfect
example of that is the plug socket, an abstraction used by all national
electrical systems to allow household appliances and electronic devices to
interact with the power supply through given voltage, frequency, and plug
type standards.
The above diagram shows the main components that form an electrical grid:
an interconnected network for generating, transmitting, and delivering
electricity from producers to residential consumers. As we can see, each
component handles electricity in a different way and communicates with the
other using various “protocols” and “adapters” – cable lines, transformers,
and so on – with the ultimate goal of bringing it to people’s houses. Once the
residential units are connected to the grid, the electricity can be used by the
home appliances – TV, oven, fridge, and so on – through a secure, protected,
and easy-to-use interface: the AC Power Plug. If we think at how those
sockets work, we can easily understand how much they simplify the technical
aspects related to the underlying power grid: as a matter of fact, none of the
home appliances have to know how such system actually works, as long as
they can deal with that interface.
A Web API is nothing less than the same concept explained above brought to
the world-wide web: an interface accessible through the world-wide web that
exposes one or more plugs (the endpoints) which can be used by other parties
(the clients) to interact with the power supply (the data) using common
communication protocols (HTTP) and standards (JSON/XML formats).
Throughout this book, the term Web API will be used interchangeably to
mean both the interface and the actual web application.
1.1.1 Overview
Let's now visualize the purpose of a Web API within a typical Service-
Oriented Architecture (SOA) diagram – an architectural style built around the
separation of responsibility between various independent services that
communicate over a network.
Web App #1, such as a React informative website, that fetches data
from the Web API to display them to the end-users through HTML
pages and components.
Mobile App #1, such as an Android app, as well as Mobile App #2
(which can be the iOS port of the same app), that also fetches data and
shows them to end-users through its native UI.
Web App #2, such as a PHP management website, accessing the Web
API to allow the administrators to interact with and possibly modify the
data.
Cloud Service #1, such as a Data Warehouse, that periodically pulls
data from the Web API to feed its internal repository (for example to
persist some access logs).
Cloud Service #2, for example a Machine Learning software, that
periodically retrieves some test data from the Web API and uses them to
perform predictions and provide useful insights.
Let’s see how we can instantiate the abstract concept depicted by the previous
diagram into a concrete, credible, and realistic scenario.
Everyone knows what a Board Game is, right? We’re talking of those
tabletop games with dice, cards, miniatures, and stuff like that. Suppose we
work in the IT department of a board gaming club; our club has a database of
board games with their gaming info such as Name, Publication Year, Min-
Max players, Play Time, Minimum Age, Complexity, and Mechanics, as well
as some ranking stats (number of ratings and average rating) given by club
members, guests, and other fellow players over time.
Let’s also assume that the club wants to use this database to feed some web-
based services and applications, such as:
Figure 1.3 Several board-game related web applications and services feeded by a single
MyBGList Web API
Again, the Web API is the playmaker here, fetching the data source
containing all the Board Games relevant data (MyBGList DBMS) and
making them available for the other services. Let’s give a more detailed
description for each one of them:
Since we've mentioned Jamstack early on, it might be worth to briefly explain
the meaning of this term. Jamstack (JavaScript, API and Markup) is a
modern architecture pattern based on pre-rendering the website into static
HTML pages and loading the content using JavaScript and Web APIs. For
further information regarding the Jamstack approach, check out the following
URL: https://jamstack.org/
Without further ado, that’s the Web API we’ll be working with through the
following chapters.
For reasons of space, I’ve intentionally restricted this book’s topics to HTTP
Web APIs only, thus skipping other application layer protocols such as
Advanced Message Queuing Protocol (AMQP). If you’re interested in
knowing more about message-based applications through AMQP, I strongly
suggest reading the RabbitMQ in Depth book, available at the following
URL: https://www.manning.com/books/rabbitmq-in-depth
Before looking at the various architectures, let’s briefly summarize the four
main scopes of use where in which each Web API commonly falls: public
(open), partner, internal (private) or composite.
Public APIs. Also called open APIs (to not be confused with the
OpenAPI specification). As the name suggests, such term refers to those
APIs that are meant to be available for use by any third-party, often
without access limitations. These APIs typically involve no
authentication and authorization (if they are free to use), or a key or
token authentication mechanism if they need to identify the caller for
various reasons (such as applying per-call cost). Furthermore, since their
endpoints are usually accessible from the world-wide web, Public APIs
often make use of various throttling, queueing and security techniques to
avoid being crippled by a massive number of simultaneous requests, as
well as Denial of Service attacks.
Partner APIs. The APIs that fall into this category are meant to be only
available to specifically selected and authorized partners, such as:
external developers, system integrator companies, whitelisted external
IPs, and the likes. Partner APIs are mostly used to facilitate Business-to-
Business (B2B) activities, such as an e-commerce website that wants to
share its customer data to a third-party business partner that needs to
feed its own CRM and Marketing Automation systems. These APIs
typically implement strong authentication mechanisms and IP restriction
techniques to prevent them to be accessed by unauthorized users, and
they’re definitely not meant to be consumed by end-users or “public”
clients such as standard web sites.
Internal APIs. Also known as private APIs. These APIs are meant for
internal use only, such as to connect different services owned by the
same organization and often hosted within the same Virtual Private
Network, Web Farm or Private Cloud. For example, an internal API can
be used by the internal Enterprise Resource Planning software to
retrieve the data from various internal business sources (payroll, asset
management, project management, procurement, and so on), as well as
creating high-level reports, data visualizations, and more. Since these
APIs are not exposed to the outside, they often implement mild
authentication techniques, depending on the organization’s internal
security model, and scarce performance and load-balancing tweaks.
Composite APIs. Sometimes referred to as API gateways. These APIs
combine multiple APIs to execute a sequence of related or
interdependent operations with a single call: in a nutshell, they allow
developers to access several endpoints at once. Such approach is mostly
used in microservice architecture patterns, where executing a complex
task can require the completion of a chain of sub-tasks handled by
several services in a synchronous or asynchronous way. A composite
API, mostly acts as an API orchestrator, ensuring that the various sub-
tasks required to perform the main call are successful and capable to
return a valid result (and invalidating the whole process in case they
aren’t). A common usage scenario is when we need to ensure that
multiple third-party services fulfill their respective job, such as when we
need to permanently delete a user record (and all its personal info) in our
internal database AND in several external data sources without the risk
of creating atomicity issues – such as leaving some potentially sensitive
data somewhere. Since the orchestrated calls can be of multiple types
(private, partner or private), composite APIs often end up being an
hybrid mix: that’s the reason why they are generally considered a whole
different type.
REST