Spring Boot business API

SPEC

Technical spec

Backend: Java 17
Spring Boot
MyBatis
Data: PostgreSQL

FIT

A good fit when

Screens and external systems have to share the same business data
Existing APIs have grown without shared rules for permissions and error handling
An integration specification has to be handed over as a document

PREBUILT

Example components

These components illustrate the proposed structure. Template features and scope will be confirmed after implementation and verification.

Authentication and authorization layer: Login, token verification, and role-based access control are already running.
Standard response and error format: Success and failure response shapes and the error code scheme are settled, so the client side has one rule to follow.
List, detail, and write operations: Listing, detail lookup, create, update, delete, paging, and sorting all follow the same convention.
Generated API documentation: The setup that produces the integration spec from the code is included, so no document is maintained separately.

The layout and design are adapted to each project.

SCREENS

Example screens

Example screens to explore layouts and flows. The final template design and style have not been decided yet.

A registration screen with metadata fields such as title, description, and provider, plus data type, URL, and run interval inputs. — Integration registration · Metadata and the call interval are entered, and the response is checked right away.

SCOPE

In scope

Deliverables

REST APIs within the agreed scope
API specification documentation
Test code and execution results

In scope

Domain and business-rule capture
API design, implementation, and permission handling
Database schema alignment and query optimisation
Verification against the acceptance criteria and one revision round

Out of scope

Full frontend development
Complete migration of an existing legacy system
Continuous monitoring of production servers
Licences for third-party commercial products

Scope and exclusions are defined before the work starts. The schedule and detailed terms are fixed in the SOW after we talk.

The problem this solves

When each screen handles data its own way, the same task produces different results. Collecting business rules in the API makes screens and external systems work from the same criteria.

How it runs

Review the domain, business rules, and permission model.
Fix the API list, request/response specification, and acceptance criteria in the SOW.
Implement the APIs and verify behaviour with test code.
Deliver with the specification documentation for acceptance.

Scope versus additional development

An API in the SOW that does not meet its specification is a defect. New endpoints, new business rules, and new integrations are additional development and are quoted separately.

FAQ

Frequently asked questions

Do we have to keep the existing database structure?: The existing structure is used first. If changes are needed, the impact is reviewed and reflected in the SOW.
Can we pin the Java or framework version?: Yes, to match the production environment. The pinned versions are recorded in the technical-environment section of the SOW.

Need a particular setup?

Tell me which screens and integrations you need, and I will come back with what is feasible.

Ask about this setup