You can use
CA Live API Creatorin the context of multiple (concurrent) API developers or as a single, disconnected API developer. If you are using
CA Live API Creatoras a single, disconnected API developer, you can use the single-user demonstration package of
CA Live API Creatorthat is based on Jetty (the demonstration package). You can support team development by using a blend of the demonstration package and other Java container deployed environments. The demonstration package installation includes an admin repository to support your development locally.
For more information about the admin repository, see View your API Definition.
In this article:
API Lifecycle Management
You can script the following API lifecycle management tasks:
- Lifecycle operation.For example, you can script the movement of a system from development, to test, and then to production.
- The API-to-API server deployment from source control system (SCS) artifacts.For example, you can save development artifacts and export admin contents into a file for maintenance into an SCS (such as the export artifact).
- The creation of APIs into an API server in a production system.
With team development, the team of API developers can:
- Work in parallel and develop code independently in their own environment, avoiding potential concurrency issues or overwriting code developed by other API developers. As the API developer changes their API, API Server writes these changes to the admin repository that is located in the API developer's file directory. The synchronization process inCA Live API Creatorattempts to match the file system with the data model that is stored within the in-memory Derby database for the API developer's API metadata.For more information about the admin repository, see View your API Definition.
- Perform code review activities, such as comparing (files) to determine how or whether the files differ (code diff) and code merges, offline.
- Check in their final code to an SCS after completing the code review.CA Live API Creatoris not bound to a specific SCS.
- Automate the deployment of API changes to other environments using existing Continuous Integration/Continuous Deployment (CI/CD) and DevOps processes.
Team Development Workflow
Most projects engage a team of API developers. The following illustration depicts a typical team development workflow using
CA Live API Creator:
API developers design their APIs locally on their
CA Live API Creatorinstance using the following process:
- Typically, each API developer works in their local instance ofCA Live API Creator, accessing either a local or shared application development database. API developers can use the demonstration package or runCA Live API Creatoron Apache Tomcat or in another Java container.
- Each API developer sets up their local instance ofCA Live API Creatorby completing the following steps:
- Stops API Server.
- Checks out or clones their API from your Source Control System (SCS) to the admin repository. For example, the API developer can copy an existing Git repository by issuing thegit clonecommand.The API name and the URL fragment of the API that you are pulling into your local instance must not conflict with any existing APIs.
- Changes their API.
- When the API developer is ready to check in code or update their environment with the latest changes from the SCS, the API developer does the following:
- Stops API Server.
- Performs code diffs, merges, and updates within the directory for their API (theteamspaces/apis/<urlname>directory that is in the admin repository). For example, the API developer can use Git.
- Updates theteamspaces/apis/<urlname>directory with the latest changes from the SCS.
- Restarts API Server.Reload the schema to see new database objects. For more information about how to reload schemas, see Database Administration.
API developers repeat these steps iteratively throughout the development process.
The following illustration depicts a typical DevOps workflow using
CA Live API Creator:
DevOps deploys APIs after an API developer has verified that their code has merged or updated successfully. The API developer repeats steps 1 and 2 as needed.
Use the following process:
- When the API developer is ready to check in code into the SCS for deployment, the API developer exports the API (the ZIP or JSON file), and then checks in this exported file into their SCS.
- Using existing CI/CD and DevOps processes, the API developer completes the following steps:
- If their API authenticates API users using a custom authentication provider and you are moving your API from one TeamSpace to another, scripts the import of their previously exported authentication provider from their local development environment from their SCS into the TeamSpace.For more information about how to script the import of authentication providers into TeamSpaces, see Import and Export Authentication Providers.
- Imports the exported API (the JSON or ZIP file) into their test environment.For more information about how to import an API using scripts, see Import and Export APIs.
- Fixes the imported API.For more information about how to fix imported APIs, see Import and Export APIs.
- Runs their automated test suites using their testing framework.
- The API developer deploys the API to the production environment by usingoneof the following options:
- Importing the API (the ZIP or JSON file).
- Checking in the API (the ZIP file), then passing in the repository URL location by way of adding theLAC_REPOSITORY_CONFIGURATION_URLoption when you start API Server.
Team Development Best Practices
We recommend the following best practices when working as a development team using
CA Live API Creator:
- If your API is using data sources, you can export your API with data source passwords as encrypted or plaintext using the API export options. While the practice of exporting data source passwords in plaintext is not recommended as you deploy to test and production environments, this practice can be useful during the initial stage of development. You can share and restart an API development or sample project that requires database schema and meta information.
- After importing an API with the latest changes in your development environment, consider reloading the schema especially when the schema is still evolving.
For a list of all best practices, see Best Practices.