Business Logic API Project Sample

The Business Logic API sample demonstrates how you can eliminate a significant obstacle in building and running modern systems for integration and mobile data access using Live API Creator. The sample is a small but representative sample application.

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 image shows the schema:

You can view a demonstration of how to building a server in under five minutes that would otherwise require weeks, by reviewing the business-oriented introduction to Live API Creator video.

For more information about this video, see Videos.

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. So, make the requirements 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. The following image shows the basic schema in Data Explorer (click the thumbnail to see the full screen):

You might provide a user interface (using Data Explorer) or build a user interface using JavaScript/HTML5.

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 API Creator to your database through the browser, which automates the web service layer and data access. Since API Creator is a service, you do not need to install or configure. Tables, views, and stored procedures are REST resources. You can build client apps for "admin" tables that do not require logic or retrieval with related data. Even faster, you can test them in the REST Lab without writing a program.

The Business Logic API is automatically created in your account. You can examine (or repair!) it using the file.

For more information:

Custom Multi-Table REST Resources

If you use these resources to present related data, one message for each table (Customer, Order, Items) appears. That can result in latency and affect performance. The following image shows the related tables listed on Create, Resources, Resource tab for the Demo API:

You can define custom, multi-table resources that deliver this data in a single JSON response. Select the tables. API Creator defaults the sub-resource join (Customers/Orders) from the foreign key validations.

You can control which attributes are returned to the client, their alias names. You can also define resources using JavaScript. After you define your resource, you can test it in the REST Lab. The following image shows the REST Lab (click the thumbnail to see the full screen):

Automation includes support for enterprise-class level services such as pagination, optimistic locking, and change summary information for client refresh.

For more information:

      • About resources, resource attributes, and defining resources using JavaScript, see Customize your API.
      • 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. The following image shows the use case and dependencies:

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 spec. But it represents quite a lot of business logic.

First, identify all the related use cases that must also respect these rules. If you miss one, you will get bugs. Each of these must be then designed for change detection, and propagation to dependent data. And optimized. Pretty 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 they were executable.

Declare your Business Logic

Presumptions can hide opportunities. Consider the presumption that domain-specific logic requires domain specific code. It is a big assumption, around 500 lines of code. That 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 our server for each use case/dependency, you could just directly enter the requirements from the cocktail napkin, as shown in the following image? That would be simple and fast. And it's exactly what Live API Creator does.

The following image shows all of the logic required to supplant 500 lines of code:

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 use their column values to filter queries against other tables. For example, you might filter orders for a sales rep to just the ones assigned to them, without the ability to alter the paid flag. As with logic, security is point-and-click, not code.

For more information about an example of filtering orders, see Demo API Security.


  • 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, so scales 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. API Creator takes care of the order through logic dependency analysis. This is repeated on every change, so maintenance is simple, just change the logic.
  • API Creator does not optimize your logic. That is API Creator's responsibility. So your logic is pruned 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 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 Debugging.

Subpages (1): Demo API Security