Oracle REST Data Services (ORDS) is a free tool that enables users
to turn their Oracle databases into RESTful API Services that are
highly scalable, manageable, and secure. The databases supported
include Oracle Database 10g or above, the Oracle
Database 12c JSON Document Store, and the Oracle
NoSQL Database.
With ORDS, users can use the data management skills they possess,
such as writing SQL and PL/SQL, and tools they are comfortable with,
such as Oracle SQL Developer and PL/SQL, to define RESTful API
services for their database. ORDS stores all these definitions as
metadata inside the Oracle Database. The actual run time is the
ORDS Java jar file which is deployed on Application Servers such as
WebLogic, Tomcat, and Glassfish using the metadata definitions.
ORDS can also be run in a simple to set up standalone mode for
development and testing purposes that does not require an
Application Server. No Java programming skills are needed to
develop RESTful services or to run ORDS.
Why should you turn your Oracle Databases into RESTful API
Services? RESTful APIs have many significant advantages which we
will describe in this blog post. REST access, though, is very
different from conventional client drivers and requires a different
style of application development.
Better Separation of Development
and Data Access Roles
Database application development requires a broad range of skills.
This includes database access skills, such as SQL for accessing
relational databases, and what may be called more pure application
development skills. ORDS allows individuals to perform this full
range of functions or have individuals with strong database and SQL
skills, who we will call data managers in this blog post, develop
the RESTful API services and have others with strong development
skills, who we will call application developers, focus on the more
pure development tasks.
This separate focus allows both functions
to be performed at the highest level. Data managers can ensure
that data access is fully scalable, uses the full power of SQL by
employing advanced features where appropriate, and is reliable,
e.g., avoids errors that may consume an inordinate amount of
resources that disrupt other processing on the database, aka
"queries from hell."
Application developers then write to these RESTful APIs, which are
simpler and don't take much code, and can focus on building great
applications. The REST APIs are also more consistent and
compatible with other application development tasks and have already
gained widespread acceptance with developers. Data managers and
application developers work together to define REST APIs that
provide the functionality needed by the application, scale well, and
are reliable. In cases where both the application and the data
management tasks require moderate skill levels, both functions can
be performed by the same individuals, aka full-stack developers, who
can bring in greater expertise if and when required.
Other benefits of this separation are that staffing may be easier and the application development process may be faster. Customers tell us that people with data management skills such as SQL are much harder to hire than application developers without SQL skills but that one data manager can support a large number of application developers. This separation also may speed both innovation, e.g., quick POCs and pilots, and time to market. Data managers using ORDS can provide easier and faster access to data without worrying about all of the intricate details of SQL within the application.
What RESTful APIs Look Like
You can get a sense of what RESTful APIs look like from the simple
pet store application that uses a tool called Swagger found here and shown below.
Very briefly, the resources, or objects, that are accessed are
identified with elements such as /Pet, /Store,and /User that will be
appended on the end of a URL that identifies where the resource is
located. Click on any of these, e.g., /Pet, and you will see the
requests that can be performed on that resource. Note that the
possible requests are the very same as those used by HTTP/HTTPS on
the world wide web, e.g., GET for reads, POST for inserts, PUT for
updates(upserts), and DELETE for deletes. Click on any of these
requests on the Swagger web page, e.g., GET, and you will see how
parameters are sent and results returned either as query strings
within the URL or in the body of the request in formats such as
JSON. ORDS allows you to define and route the full URLs that
identify the server, ORDS instance, application (module), and
resource, e.g., https://Myserver/Ords/Petstore/Pet,
to a handler routine that the data manager defines or has
automatically generated. The routine executes the request on the
resource, e.g., a SQL or PL/SQL statement for the Oracle Database,
passing any parameters appropriately and returning any results.
The use of JSON to send and return data is a particularly powerful
technology when used with REST. JSON stands for JavaScript Object
Notation, but pretty much all modern, and somewhat modern, languages
have excellent JSON support that enables them to readily produce and
consume JSON objects (that are often hierarchical) with very minimal
code, including Java, C#, JavaScript, PHP, Ruby, Pearl, Python, Go,
Swift, and many more.
One API
Another huge advantage of REST is that data managers, using a tool
like ORDS, can build one RESTful API that can be readily accessed by
all language environments without requiring any driver software to
be installed, managed, or upgraded on the clients. All modern
languages, and even not so modern languages such as COBOL and
Fortran, support HTTP/HTTPS and hence REST out of the box. This
ubiquitous connectivity is important because of the number of major
programming languages being used today is much more diverse than in
the past and becoming even more diverse.
For a very long time, there were just two dominant development
platforms: Java and .Net. Companies picked one or the other.
Some ended up with both, but they tended to be very separate systems
that didn't interact much or at least easily. In recent years, the
languages in major use have gotten much more diverse as can be seen
in this recent Redmonk
Programming Language Ranking. JavaScript has become a
third dominant language platform. With Node.js, JavaScript now runs
in the application server. There are other, newer languages that
are rapidly emerging such as Go from Google and Swift from Apple.
Scripting languages such as PHP, Python, and Ruby continue to be
very widely used. C#, C++, C, and Objective C remain strong.
There are many more including special purpose languages such as R
for data analysis and Scala for functional programming.
Microservices
Ubiquitous connectivity is essential, however, if you have any
thought of moving to the new microservices architectures and agile
development techniques that more and more enterprises are looking to
adopt. Microservices advocates a model of "smart endpoints, dumb
pipes" which is very different from the traditional SOA
architecture. RESTful services align themselves very naturally to
that architecture design principle, hence its wide adoption in
microservices architectures.
The new microservices architectures and agile development techniques
seek to build applications that satisfy customer requirements faster
and with less risk than the large, monolithic applications which
have been the norm for a very long time. Microservices break down
large, monolithic applications into smaller modules developed by
smaller, more autonomous teams that provide a well defined service
through an API. This architecture enables small teams to iterate
faster by providing smaller increments of needed functionality,
getting feedback from customers, and iterating again. New
functionality is offered through new versions of the API that other
microservices can adopt when they are ready. Older versions of the
API continue to be supported and are only very gradually phased
out.
The API is really key. REST ensures that the microservice you
develop can be accessed by any type of client environment instantly
(subject to access controls) without requiring any kind of connector
or driver to be developed, deployed, and maintained. Ubiquitous
connectivity also gives you the flexibility to potentially change
the microservices you are consuming. For example, if you want to
move from a NoSQL key/value store or JSON document database to a
relational database or vice versa, you can potentially do that by
developing the appropriate handlers for the new database that are
invoked by the REST API you have been using.
REST is Stateless for Performance, Simplicity,
and Reliability
One of the key principles of REST is that it is stateless, which
means everything is done with one call, i.e., one network round
trip. Each call is an autonomous, independent operation. No
state information is maintained across calls.
Client drivers may be run in a stateless, or single call, mode but
are often run with sessions, which means that everything is
typically done with many more calls and network round trips. This
can have a big impact on performance.
The number of network round trips is the biggest single determinant
of performance for most applications. Network rounds trips often
eat up significantly more time than that taken by the actual
database processing that is invoked. The total number of calls
also commonly dwarfs the impact of the efficiency of the particular
network protocol used to make each call, e.g., HTTP vs. a single
JDBC driver call.
For example, with REST if you want to read a customer's orders from
a database into an application, you make one call to get all the
data in a format like JSON, which may include a row from the
Customers table, one or more rows from the Orders table, one or more
rows from an Order_Items table for each order, and possibly other
rows from other tables with information on Products, etc. When
received, the customer's order data in JSON can be readily mapped to
objects within the client programming language. Similarly, to
insert an order into the database, you can make one call with one
JSON document containing nested data to be inserted into multiple
tables.
With conventional drivers (providing, for example, SQL access to
relational databases), the customer's order data may be retrieved
from the database or inserted into the database with multiple calls
with state being maintained across these calls to track what is
going on within the session. For example, there could be one call
to retrieve the row from the Customers table, another to get rows
from the Orders table, others to retrieve the Order_Items rows, and
so on. There may be other calls to prepare, bind, and execute
statements and fetch individual rows one by one. Alternatively,
you could try to retrieve all the data in one big join and then try
to pick apart the individual order components in the application
code if you are up for that.
Not having sessions is a good thing for more than just
scalability. REST draws on core principles of the World Wide Web,
perhaps the most fundamental of which is being stateless.
Statelessness is a core reason behind the web's simplicity,
scalability, and reliability. Sessions complicate things and make
systems more fragile. Some examples:
- Connection pools are more complicated, less efficient, and
more fragile when they support database sessions instead of
stateless connections. ORDS uses the Oracle Universal
Connection Pool (UCP) under the covers, but it is run in a
stateless mode which makes it simple, efficient, and reliable.
In fact, one particularly efficient way of running ORDS, which
Oracle uses internally and for cloud services, is to just use
one common pool configured in a standard way for many, or even
all, applications. This is much more efficient, reliable, and
convient than having to set up connection pools specially
configured, tuned, and managed for each application, which you
may well end up doing if you use sessions.
- Client driver sessions with the database may not work well
from Mobile clients. Mobile, almost by definition, has to be
able to deal with intermittent connections which play havoc with
database session reliability. It also may be impractical to try
to deploy client drivers and maintain them, e.g., upgrade them
when newer versions come out, on large numbers of remote
devices.
Secure
The RESTful API Services that ORDS creates are secure because they
provide:
The Full Protection of Application Servers
For production deployments, ORDS runs in Application Servers such as
WebLogic, Tomcat, and Glassfish and benefits from all the security
protections provided by these systems. For example, ORDS uses the
authentication and authorization mechanisms provided by the
Application Server to manage users, passwords, privileges, and roles
and authenticate users when they log in.
One Stack to Secure
ORDS enables you to implement a single REST API service that can
support all client environments as described above. This means
one stack to secure. With conventional client connections you
need to secure each stack your service needs to support, e.g., Java,
.Net, PHP, etc. This is a lot more work and may incur a greater
chance of getting something wrong. With ORDS there is also just
one place to maintain database login credentials instead of
potentially many.
Reduced Attack Surface
With ORDS you secure the RESTful APIs you define. If there is a
breach, then just these APIs are exposed. Conventional client
drivers expose direct SQL connections into the database which can
also be made secure but have a greater attack surface. In theory,
the connections should be authorized with just the "least privilege"
needed to run the application. In practice, true "least
privilege" implementations may not be done because they take a lot
of work to configure initially and to maintain. (In Oracle
Database 12c, Oracle has introduced Privilege Analysis to make this
easier.) The connections also have direct access to the database
data dictionary and the full power of SQL. The potential for doing
large scale damage to your data and/or very subtle and hard to
detect changes may be greater.
OAuth 2.0 Security Standard Support
ORDS also supports the OAuth 2.0 security standard used by other
advanced Internet vendors such as Google, Amazon, Microsoft Azure,
Facebook, and many others.
Oracle REST Data Services
Oracle REST Data Services, or ORDS, makes it easy to develop and
expose REST APIs to relational data in the Oracle Database, JSON
documents in the Oracle Database 12c Document Store using the Simple
Oracle Document Access (SODA) API, and the Oracle NoSQL Database.
It is highly scalable, running within popular application servers
such as Oracle WebLogic, Tomcat, and GlassFish, or in a simple, easy
to deploy, standalone mode for development and testing. It
provides security in compliance with the OAuth 2.0 security
standard. For relational data in the Oracle Database, ORDS can
automatically generate REST APIs for basic single table operations
such as query, insert, update, and delete and supports the
development of more complex operations with SQL and PL/SQL using
Oracle SQL Developer or PL/SQL. Developers can use query filters
to specify basic query selection predicates and sorts in a
query-by-example format using JSON. ORDS returns results in JSON,
CSV, or (using Oracle XML DB functionality) XML formats to the
client application. For more information, including downloads,
documentation, blogs, and videos, see the Oracle Technology Network
webpages for ORDS here.