Interface Logic Versus Business Logic
In developing services, it is common to distinguish interface logic from shared business logic. These same concepts exist in :
In developing services, it is common to distinguish
interface logicfrom shared
business logic. These same concepts exist in
CA Live API Creator:
Point-and-click resource creation (including multiple data sources).
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).
Extend with request event handlers.
Business logic and security, which
CA Live API Creatorautomatically 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 logicis 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 logicis logic that is defined for entities (tables and views) as reactive logic.
CA Live API Creatorshares 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.
Because business logic is the point of highest reuse, it is good practice to use it to the maximum practical extent.
For more information: