Application integration
A database query reads data from a system you usually control. A REST API reads or changes data through another application's published interface.
From the user's point of view both may appear as a table or form, but the application has to handle network requests, JSON, authentication, rate limits, and external failures. PHPRunner can expose REST data as a data source or call an API as part of a business action.
The page or workflow that needs external data or action.
GET, POST, PUT or PATCH, or DELETE plus parameters and authentication.
The external system processes the request under its own rules and limits.
The application maps returned fields, errors, and identifiers into its own workflow.
Quick answer: Treat a REST API as an external dependency, not merely a remote table. Understand the request method, authentication, data format, paging or limits, failure responses, and how external IDs map to your own records.
Most APIs have a stable service root and variable endpoints or parameters.
A request URL may contain the base API address, a resource such as customers or orders, filters, paging, and other parameters. Splitting those pieces conceptually makes integration easier to configure and debug.
Test the endpoint independently first. Confirm what a successful response looks like before building application pages around it.
The HTTP method is part of the API contract.
| Method | Typical use | Application concern |
|---|---|---|
| GET | Read data | Filtering, paging, caching, rate limits |
| POST | Create or trigger an operation | Validation, returned ID, retries |
| PUT / PATCH | Update an external record | Partial vs complete update, conflict handling |
| DELETE | Remove an external record | Permissions, irreversibility, idempotency |
External services fail differently from local database queries.
A network can time out, credentials can expire, rate limits can be reached, and the remote service can return a successful HTTP connection with a business-level error inside the response.
Decide whether the user should retry immediately, whether the operation can be queued, and whether your database should store the last successful external state. Integration design is as much about failure behavior as the happy path.
The goal is to keep the architecture understandable while reducing repetitive application work.
PHPRunner can consume REST data and can also call external APIs from application logic, allowing external services to participate in normal forms, pages, and workflows.
| Need | PHPRunner approach |
|---|---|
| REST data | Use REST connections or views where the external service can be treated as a data source. |
| Custom requests | Call APIs from application events when the integration is an action rather than a normal table. |
| Data mapping | Transform JSON fields and external identifiers into application-friendly values. |
| Hybrid workflows | Combine your own database records with external API data and actions in one application. |
An API integration is a contract with a system outside your application.
Build the first successful request, then spend equal attention on authentication, errors, retries, data mapping, and what happens when the other system is slow or unavailable.
That approach turns a demo integration into something users can rely on.