Database as a Service (DBaaS) and

Data APIs

Databases are at the core of data-driven applications. Among the different types of
available database deployment options, the usage and popularity of cloud databases and
DBaaS (Database-as-a-Service) offerings have been growing like never before. According to
a recent ResearchAndMarkets.com report, cloud databases are the fastest-growing
segment of cloud services, projected to generate $320 billion by 2025.

Imagine that you’re building a brand new app and need to get it to market as quickly as
possible. You don't have the time or resources to worry about hardware procurement,
software installation, configuration, and ongoing maintenance. Managed databases enable
you to reduce this operational overhead using a set of simple API calls or with just a few
clicks on the UI to spin up and manage databases.

With managed databases, enterprises are not bogged down by the "grunt work" of
managing costly physical database infrastructure, mitigating security risks, scaling,
storage, and other operational costs such as additional human capital to keep the service
up and running. As a result, developers can devote more time to critical tasks, such as
improving developer agility and innovating, leaving the rest to the provider running the
managed database service.

What is Database-as-a-service (DBaaS)?

In a nutshell, DBaaS is a cloud-based database service that includes everything needed to
run a database in the cloud, including hardware, software, licenses, support, and
operational maintenance. As a result, users can quickly spin up and run distributed
databases that live in the cloud, paying only for the time they use them. Using DBaaS have
several key benefits -

1. Cost effectiveness – Setting up physical infrastructure for building an application is

one of the most significant expenses. It is also time-consuming which requires a
dedicated workforce to set up, maintain and support on-premise infrastructure.
With DBaaS, all these costs and resources are handled by the service provider.
Enterprises using DBaaS solutions are charged based on their consumption.
 2. Improved scalability – If you have Database infrastructure that you manage, you
need automation in place to ensure scaling based on traffic. This is where DBaaS is
most effective. With DBaaS, you don't need to purchase any additional capacity of
infrastructure or have automation and management in place for hypothetical future
needs -- the provider continually expands or shrinks your storage capacities and
compute resources based on traffic. Additionally, with autoscaling turned on, you
can remove the grunt work of complex capacity planning. With this additional
flexibility, you will be able to meet both surging demands and periods of low activity.

3. Rapid development – With a DBaaS model in place, data operations are highly
simplified. Unlike traditional on-premise database systems, developers don't need
to go through the time-consuming database provisioning process, which can take
days or weeks. Rapid on-demand database provisioning using DBaaS and better
integration with other data solutions in the cloud can drastically shrink the time to
market for a new app feature.

4. Better data and application security – Meeting regulatory compliance

requirements can be a challenging and costly affair. DBaaS solutions provide
enterprise-level data security, which meets specific regulatory compliance
standards like HIPAA (for health industry), FedRAMP (for defense), NERC CIP (for
electrical power infrastructure), etc. DBaaS solutions also provide native security
features like data encryption to protect sensitive data at rest and in transit.

DBaaS is an effective way to get your database up and running quickly. Still, it will not
automatically solve your application architecture issues. Additionally, if your application is
tightly coupled with a DBaaS service, it will be challenging to move your application to
another DBaaS service in the future. This is where a Data API approach is beneficial.

What is a Data API?

Data APIs provide a way to loosely connect the frontend application logic directly to a
DBaaS or similar system through a secure and fast-scaling API with a standardized query
and response format. In fact, by using an API-based approach, you can break the tight
coupling of the application from the database so that you can benefit from the reusability
of the data and portability of your code.

While DBaaS significantly disrupted the world of database management, Data APIs
represent the next evolution in how applications are built. With data APIs, you get the same
power of a DBaaS, along with other unique advantages such as data safety, security, and
scalability characteristics.
API
These APIs provide a standardized way for two applications to communicate, which enables your
software to interact efficiently with various other services, thereby enhancing its capabilities and
user experience.

What is a REST API?

To understand what is REST API, we need to review some key terms.

• A client is a person or program using the API. The client makes requests to the API to
retrieve some information or change something within the application. Your web
browser is a client — it interacts with APIs different websites to get page content
from them. The requested info is sent back to your browser and displayed on your
screen.

• A resource is any piece of information that the API can provide the client. For
instance, a resource in Facebook’s API could be a user, a page, a photo, or a post.
Each resource has a unique name, called the resource identifier.

• A server is used by the application that receives client requests and contains
resources that the client wants. The server has an API to interact with clients
without giving them direct access to content stored in its database.

The Six Rules of REST APIs

To fully benefit from the functionality that REST provides, APIs must follow six
requirements. (Well, technically five are required and one is optional.) Each requirement
lays the groundwork for a fast and versatile API.

1. Client-Server Separation

Under REST architecture, the client and server can only interact in one way: The client
sends a request to the server, then the server sends a response back to the client. Servers
cannot make requests and clients cannot respond — all interactions are initiated by the
client.

2. Uniform Interface
This guideline states that all requests and all responses must follow a common protocol, or
a way of formatting their messages. Applications and servers are written in all sorts of
different languages that don’t do a great job of working together without an intermediary. A
uniform interface is a common language for any client to communicate with any REST API.

Without standardized communication, translating requests and responses between

software would be a total mess. Minor discrepancies would cause information to be
jumbled and lost, and applications would have to update their request processes
whenever APIs updated theirs. A uniform interface eliminates this possibility.

Like all requests to a REST API, this request contains two pieces of information:

• GET is the HTTP method. This specifies the action the client wants to make on the
resource. There four basic HTTP requests a client can make are:

o GET: To retrieve a resource.

o POST: To create a new resource.

o PUT: To edit or update an existing resource.

o DELETE: To delete a resource.

• https://… is the URL. The URL contains the uniform resource identifier, or URI,
which specifies the target resource.

3. Stateless

All calls with a REST API must be stateless. This means that every interaction is
independent, and each request and response provides all the information required to
complete the interaction. Every request by the client is interpreted by the server as a brand
new ask — the server remembers nothing about past requests.

4. Layered System

So far I’ve described API requests as a simple interaction between a client and server, but
this is a bit of a simplification. In reality, there are typically more servers between these two
entities. These servers, or layers, are there to add security, handle and distribute traffic, or
assist with a number of other important functions.
This principle requires that messages between the client and target server should always
be formatted and processed the same way, regardless of layers that sit between them.
Additional layers should not affect client-server interactions.

5. Cacheable

Caching occurs when media is stored on a client’s device when visiting a website. When a
client returns to that site, the cached data is loaded quickly from local storage instead of
being fetched again from the server. Caching saves server resources and bandwidth while
decreasing page load time, which is why most large websites do it.

REST APIs are created with data caching in mind. When a server sends its response to a
client, the response should indicate whether the resource provided can be cached, and for
how long.

Difference in REST

Bibliography:

https://blog.hubspot.com/website/what-is-rest-api

https://fauna.com/blog/database-as-a-service-dbaas-vs-data-apis-explained

https://medium.com/@dharshithasrimal/php-rest-api-7441197312d7

https://www.howtographql.com/basics/1-graphql-is-the-better-rest/