Managing APIs‎ > ‎Team Development‎ > ‎

Separation of Concerns

One of the key principles of software engineering is to architect a system into subprojects that can proceed independently. This page describes how Live API Creator helps your team organize into parallel projects, based on separation of concerns (SoC).

The following image shows how Live API Creator addresses SoC:

Clients

It is common for client applications to be burdened by providing services like pagination, optimistic locking, or generated key handling. These are properly partitioned to the API Server. Clients interact with service endpoints, which provide the following services:
  • Connectivity. Virtually all languages facilitate HTTP/RESTful APIs..
  • Custom Resources - the Database abstraction layer. API Creator facilitates client development through customized resources that select the correct columns, alias them, and join multiple objects together so they can be retrieved simply, in one trip.  Since re-use of underlying logic is automatic, you can easily define multiple client-specific Custom Resources, while being assured of logic re-use.
For more information about customized resources, see Customize your API.
  • Object model. Some languages are built around objects. For example, Java Plain Old Java Objects (POJOs) and .NET Plain Old CLR Objects (POCOs). You can create such objects using Swagger SDKs.

    For more information of the Object Model and logic re-use, see Object Model.
  • Application partitioning (no "fat client"). Effective applications depend on proper partitioning of logic between the client and server. This is often a source of architectural error, resulting in duplicated / inconsistent logic, poor performance, and unavailability of logic for non-interactive applications. The following services provide meaningfully improved re-use and reduced development time.
  • Pagination. Pagination breaks large result sets into page-size chunks, to ensure good performance. This is often part of client database-handling code. API Server provides pagination.
For more information about pagination, see Architecture.
  • Optimistic locking. Optimistic Locking is a commonly accepted approach for increasing concurrency by enabling updates to unlocked data. This requires various mechanisms (timestamps, checksums etc) that often require client code. API Server provides optimistic locking.
For more information about optimistic locking, see Performance.
  • Logic. While it is an anti-pattern, business logic for database integrity is often placed in client applications. This leads to poor performance (multiple trips), redundant / inconsistent code (due to replication), and inability to access logic (for example, for Web Services). API Server provides reactive logic, so that such logic is factored out of client, and significantly more concise.
For more information about reactive logic, see Declare your Logic.
  • Security. Typical applications include substantial logic on the controller buttons to inject security filters into queries, for example, to ensure a sales rep sees only their own orders. Such logic is tedious and difficult to ensure compliance. API Server enforces role-based row/column-level access.
For more information about role-based row/column-level access, see Control Access to REST Endpoints. 
  • Primary key generation. Consider creating an order, with a set of line items. If the order has an automatically-generated key, the client could be forced into multiple server interactions:
  • Insert the order and obtain the generated key.
  • Insert the items, having placed the OrderID into each item.

This is a lot to code, and performs poorly due to multiple server trips. API Server provides services for primary key generation. You define a resource that includes the related data and submit it. This partitions the logic to the server.

For more information:

Service Endpoints

A non-trivial architectural challenge is where to place business logic. Is business logic placed in each service? Is it placed in underlying domain objects? Live API Creator factors this logic out of the services. All requests automatically enforce your logic and security.

Reactive Logic

A typical first step for implementing business logic is to create an object model. Live API Creator creates that automatically.

For more information about the JavaScript object model, see Customize your API.

Database

You can iterate your database with minimal effect on clients, since services hide the underlying data model. When the data model changes, you can run Verify to rebuild the object model and determine which services/logic require re-targeting.