Interface Logic Versus Business Logic

In developing services, it is common to distinguish
interface logic
from shared
business logic
. These same concepts exist in
Layer7 Live API Creator
Defined On
Typical Uses
Point-and-click resource creation (including multiple data sources).
Extend with:
Provide APIs for API consumers with more interface logic to optimize output and reduce latency.
Match external API agreements, particularly in the request and response formatting, for both retrievals and updates.
Entities (Tables and Views)
Spreadsheet-like validation rules and derivation rules (for example, formula rules, sum rules, and count rules).
Row permissions.
Extend with request pipelines.
Business logic and security, which
Layer7 Live API Creator
automatically invokes and re-uses across resources.
API Server fire validation rules and request pipelines only on update operations.
For practical examples of interface logic and business logic, see B2B API Sample.
Interface Logic
Interface logic
is logic that is specific to a service. When you require logic specific to a current service, you can define resources explicitly in your API and then extend them, for example, with request pipelines, request/response transformation, and metadata action tags.
Many of the concepts that describe interface logic in the resources that you define explicitly in your API are available in the Business to Business (B2B) sample.
For more information about the B2B sample, see B2B API Sample.
Business Logic
Business logic
is logic that is defined for entities (tables and views) as reactive logic.
Layer7 Live API Creator
shares this logic across all resources that you explicitly define in API Creator and associates it with the row objects. This automatic sharing is a consequence of the resource/row mapping, described in logic execution.
Business logic describes your API's business logic, expressed by reactive logic such as:
  • Validation rules
    : Expressions that are assigned to an entity that must be true for a transaction to commit (else the transaction is rolled back and a suitable message is returned to the client).
  • Derivation rules
    : Spreadsheet-like rules for table/column derivations. For example, formula rules, sum rules, and parent copies. The rules chain to address multi-table transactions.
  • Event rules
    : Server-side JavaScript-code business logic that you assign to tables and that fire when the tables are updated.
Because business logic is the point of highest reuse, it is good practice to use it to the maximum practical extent.
For more information: