Demo API Sample

Demo API Sample
calac41
The 
Demo
 API is a small but representative sample application that illustrates basic 
CA Live API Creator
 concepts. It demonstrates how you can eliminate a significant obstacle in building and running modern systems for integration and mobile data access using 
CA Live API Creator
. It illustrates rules on the smallest database we believe is worth exploring. The Demo database is included with the 
Demo
 API sample.
The 
Demo
 API sample is included with the single-user demonstration package of 
CA Live API Creator
 that is based on Jetty and with the 
CA Live API Creator
 Docker container installation. No additional steps are required to load this API.
You can also load this API sample if you have installed 
CA Live API Creator
 on another container.
The following image shows the schema for the 
Demo
 API sample:
MySQLWorkbenchScreenSnapz001.png
In this article:
 
 
3
 
 
Problem: Servers are Hard to Build, Particularly the Business Logic
REST/JSON servers are the accepted approach for mobile app access to integrated data. But these are slow and complex to build. In a Java stack, you might need to use Jersey, Jackson, JPA, etc. These frameworks can reduce coding, but these are complex and time-consuming. And worse, they do not address business logic and security, which can comprise significant effort. What is the absolute fastest and easiest way to build a REST server?
The following sections further describe how to build a server. The business logic requirements–which can be expressed in five lines, clear to IT and business users alike–require hundreds of lines of code to implement. The requirements must be executable. Provide a user interface that:
  • Accepts spreadsheet-like expressions that express what your data means, how it is computed, validated, including actions (auditing, deep copy, etc), and so forth.
  • Directly executes this spreadsheet-like logic on all RESTful update requests (PUT, POST, and DELETE).
Sample Problem
To make things more definite, you can use a familiar sample problem: Customer, Order, Items, and Parts. You might provide a user interface (UI) (using Data Explorer) or build a UI using JavaScript/HTML5. The following image shows the basic schema in Data Explorer:
Screen Shot 2015-10-28 at 9.43.16 AM.png
Complete the following process:
  1. Expose database tables as REST resources.
  2. Declare your business logic.
  3. Declare security for a public API.
For more information:
Expose Database Tables as REST Resources
To build a REST server, connect your API to your database, which automates the web service layer and data access. Since 
CA Live API Creator
 is a service, you do not need to install or configure. Entities (tables and views) and stored procedures are REST resources. You can build client applications for "admin" entities that do not require logic or retrieval with related data. You can test the entities and stored procedures in the REST Lab without writing a program.
You can examine (or repair!) the Demo API sample using the  file.
For more information:
Custom Multi-Table REST Resources
If you use the REST resources to present related data, a message for each table (
Customer
Order
Items
) appears. Using these resource can result in latency and can affect performance. The following image shows the related tables for the Demo API in API Creator:
  Screen Shot 2017-06-15 at 2.20.07 PM.png
You can:
  • Define custom, multi-table resources that deliver this data in a single JSON response. Select the tables. API Creator defaults the subresource join (Customers/Orders) from the foreign key validations.
    For more information about resources, resource attributes, and how to define resources using JavaScript, see Customize your API.
  • Control which attributes are returned to the client, their alias names.
  • Define resources using JavaScript.
  • Test your resources using the REST Lab.
Automation includes support for enterprise-class level services such as pagination, optimistic locking, and change summary information for client refresh.
For more information:
  • About pagination, see GET.
  • About optimistic locking and changing summary information, see PUT.
  • About how API Creator fits into your enterprise/web architecture, see Architecture.
Business Logic Must be Addressed
The real work involves the business logic. Consider the Place Order user story. Analysis reveals your need to check credit. The balance cannot exceed the credit limit, where the balance is the sum of the unpaid order totals, which is the sum of the Line Item amounts, derived as the quantity times the parts' price. This is a nice clear requirements specification. But it represents a lot of business logic.
First, identify all the related use cases that must also respect these rules. If you miss one, you get bugs. Each of these rules must be then designed for change detection, and propagation to dependent data. And optimized. Soon, the simple five-line specification becomes 500 lines of code. And yet, the requirements, as illustrated with the venerable cocktail napkin, were so simple. If only the requirements were executable.
Declare your Business Logic
Presumptions can hide opportunities. Consider the presumption that business logic requires domain-specific code. Domain-specific code is a big assumption, around 500 lines of code. Writing the code is weeks of work to build and test and a web of dependencies to maintain. That is not fast, and it is not simple.
What if, instead of programming your server for each use case/dependency, you could simply enter the requirements from the cocktail napkin? Entering the requirements from the cocktail napkin would be simple and fast. And it is exactly what 
CA Live API Creator
 does. You can explore logic. Note the multi-table derivations, such as the customers' balance. You can chain the derivations and use them in related logic (used by the credit limit check, uses the amount_total result). API Creator eliminates and simplifies SQL access by optimizing the derivations.
For more information about exploring logic, see Logic.
Declare Security for a Public API
To make your API public, you require fine-grained security down to the row- and column-instance. You can define one or more roles for a user. You can associate roles data rows in your database and can use their column values to filter queries against other tables. For example, you might filter orders for a sales rep to only the ones that are assigned to them, without the ability to alter the paid flag. Security is point-and-click, not code.
For more information:
Observations
The Demo API sample illustrates the following:
  • You did not write any code. Not for request handling, database access, or business logic. But you can if necessary. You can extend the logic using server-side JavaScript and scale it to complexity (for example, a Bill of Materials explosion with four rules).
For more information about how the logic scales to complexity, see the Reactive Logic Tutorial.
  • You solved all the use cases, even though you targeted only Add Order. Re-use and quality are automatic.
For more information about re-use and quality, see Logic.
  • The logic is unordered. 
    CA Live API Creator
     takes care of the order through logic-dependency analysis. 
    CA Live API Creator
     repeats the analysis on every change. Maintain your logic by changing it.
  • CA Live API Creator
     prunes your logic based on actual changes, and SQLs are eliminated/optimized to reduce server traffic. As for ordering, these optimizations are repeated on each change.
    For more information about how 
    CA Live API Creator
     does not optimize your logic, see Performance.
  • Your logic is transparent. Business users can read it and spot errors/omissions. You have a common business/IT language that is both transparent documentation and maintainable implementation, which is a corporate asset.
  • You can debug your server using API Creator.
For more information about how to debug your server, see Debug.