Live API is a RESTful API:
- Default RESTful Resources (aka End Points) are created for Base Tables, View Tables, and Stored Procedures when you connect Espresso to your database
- You can also define Custom Resources in the Espresso Designer.
- For both, RESTful API provides for GET (with pagination), PUT, POST and DELETE operations, with arguments for common functions like filter and sort, including custom arguments
Live API can be tested in the RESTlab
, and is also used by Live Browser.
A useful API must provide not only access to data, but it must enforce the semantics for that data. Proper support even opens up the possibility of simple and fast Public API Creation. So, Live Data APIs enforce:
- Security at the row/column level, based on authenticated Users' roles, and
- Live Logic to enforce PUT/POST/DELETE transactional business logic that should be applied when committing a transaction. This consists of various multi-table computations, validations, and events such as auditing, cloning, sending mail, messages etc.
Live API - Process Overview
You can use Live API as summarized below:
- Connect Espresso to your database enables your default API and Live Browser
- Declare logic and security with a point-and-click interface
You begin by signing up. Espresso is a service, so there's nothing to install.
You create your API by connecting Espresso to your database. Schema Discovery finds your base/view tables and your Stored Procedures, and makes them available as REST end points. You can set default security so objects are visible only to designated roles.
You can test your API using the RESTlab
, or the Live Browser
. The Logic Designer contains a Quick Ref, so you can understand the services provided (authentication, filtering, sorting, pagination, update and so forth):
The Logic Designer provides a point / click interface to define Custom Resources and Security.
In addition to the automatic resource end points per Schema Discovery, you can define your own Custom Resources
. As shown here, you can
- define "document oriented" resources with nested sub resources, for a more convenient programming model that can reduce network latency. Joins are supplied automatically.
- alias and project your columns so your API is independent of database names
You can Authorize
which end points are visible to which roles. You can also define Role Permissions
for row and column level security, as shown here.
Roles are obtained from the Authentication process. This returns an APIKey you pass on subsequent requests.
An Authentication Provider is supplied by default, suitable for testing. For production, you will most likely want to build your own Authentication Provider, which connects to corporate security using LDAP, AD, oAuth, etc.
In the context of Espresso Logic, business logic refers to the transactional logic that should be applied when committing a transaction. This consists of various multi-table computations, validations, and events such as auditing, cloning, sending mail etc.
Transactional business logic is complementary to other forms of business logic such as process (workflow) logic, application integration, and decision logic.
Unlike conventional approaches where logic is coded in an OO or 4GL language, logic is declared in spreadsheet-like expressions.
This logic is automatically invoked as a consequence of PUT, POST and DELETE events. It is part of your Live API - you don't call it directly. The system provides for ordering, dependency management, sql handling, and optimizations such as pruning.
The system builds a complete object model