API Strategy and Architecture
The scope of this PAVE API Strategy and Architecture section is to help answer these frequently asked questions:
“Describe your API architecture (REST, SOAP). Also, describe the technology stack and hosting model for your system including the APIs.”
“How often are changes to customer-facing APIs, UI, or dashboards implemented and what is your process for notifying customers of changes?”
PAVE API Architecture
The PAVE API is organized around the RESTful (REST) construction on the PHP Laravel Framework with PHP 8.X. It serves requests via HTTPS using Laravel Octane with Swoole library (an event-driven asynchronous & coroutine-based concurrency C++ engine for PHP). Our API returns JSON-encoded responses and uses the OpenAPI Specification (OAS) that defines a language-agnostic interface to REST APIs.
Repository and Unit of Work classes are used for decoupling the infrastructure to access databases and utilizing event-driven and queue-job architecture with RabbitMQ and Redis.
The PAVE API services are deployed on Google Cloud Kubernetes.
PAVE API Change Management
We always avoid making any "Breaking Changes" to our production APIs. However, we can make these changes for any specified license on request (when any customer-specific customization becomes required) without impacting other accounts. By "Breaking Changes," we mean any structural change that would break any customer's application. In contrast, we will frequently add functionality and new objects that support our continuous improvements and new product features.
When we evolve the AP such that it requiresI changes to our Data Contracts and requires migration by our customer (by implementing "Breaking Changes"), we will always deploy this as a new version of our API to allow customers to migrate at their own discretion and schedule. We manage this using the URI Path by putting a number in the path of the URI with the prefix "v." This allows our customer to use both versions simultaneously as they complete their development and UAT testing on the newly released version.
For Example, Our current endpoint is:
When we need to make breaking changes, we would reversion this to become:
The PAVE product team includes a complete QA department that tests all functionality in staging and, when approved, to go to production, these same tests get completed again once released.
Each function of our API constantly gets tested for:
Send the request with necessary input data
Get the response having output data
Verify that the response returned as expected in the requirement
Last updated