Interface Logic Versus Business Logic

In developing services, it is common to distinguish interface logic from shared business logic. These same concepts exist in :
lac42
In developing services, it is common to distinguish
interface logic
 from shared
business logic
. These same concepts exist in
CA 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 validations and derivations (for example, formulas, sums, and counts).
Row permissions.
Extend with request event handlers.
Business logic and security, which API Creator automatically invokes and re-uses across resources.
Validations and request event handlers fire only on update operations.
For practical examples of interface logic and business logic, see Explore the 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 explicitly define resources in your API and then extend them, for example, with request events, request/response transformation, metadata action tags. Many of the concepts describing interface logic in resources that you explicitly define 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.
CA 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: 
  • Validations
    : 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).
  • Derivations
    : Spreadsheet-like rules for table/column derivations. For example, formula rules, sum rules, and parent copies. The rules chain to address multi-table transactions.
  • Events
    : 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: