Interface Logic Versus Business Logic

In developing services, it is common to distinguish interface logic from shared business logic. These same concepts exist in :
lac52
In developing services, it is common to distinguish 
interface logic
 from shared 
business logic
. These same concepts exist in 
Layer7 Live API Creator
:
Logic
Defined On
Facilities
Typical Uses
 
Interface
 
Resources
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.
 
Business
 
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 event handlers.
Business logic and security, which 
Layer7 Live API Creator
 automatically invokes and re-uses across resources.
Validation rules and request event handlers fire 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 events, 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: