Aleph Alpha Usecases API
**Usecases (Applications)** Usecases are full-stack end to end AI applications. The application exposes the necessary REST endpoints so AI usecases can be consumed and, optionally, a front-end (UI) to interact with the implemented workflows. Once you have finished the usecase implementation and have published a Docker image to a registry, it is time to deploy the usecase! The endpoints below enable you to create a usecase by providing a name and a description, list all created usecases, retrieve a single usecase by id, and update them. Also, most importantly, the API enables you to deploy a created usecase. The deployment of usecases requires some more technical information. **Deployment** We rely on [Kubernetes (K8s)](https://kubernetes.io/docs/home/) to deploy the usecases, which means that they are [Pods](https://kubernetes.io/docs/concepts/workloads/pods/) running in a K8s cluster. To deploy usecases you must provide: the registry where the usecase image is located, the image tag (version), the environment variables you wish to inject into the usecase and other K8s configurations parameters, such as `imagePullSecrets`, `autoscaling`, `ingress`, and resource `requests` and `limits` for CPU and memory required to run the usecase. A complete specification is provided further below. By default, a usecase is created with the below resources configuration: ```yaml resources: requests: cpu: 250m memory: 500Mi limits: cpu: 500m memory: 1Gi ``` The API also provides endpoints to track the deployment status to assist in any troubleshooting if required. To retrieve the deployment status, use the endpoints to get a usecase by its ID. **Consuming usecases** Once the deployment is up and running, now it's time to actually consume it! _1. (Optional) Usecase Ingress_ If the usecase was deployed with the ingress enabled, the service can be accessed at the URL provided in the deployment status. _Note: this requires that ingress creation is enabled in the PhariaOS API configuration; otherwise, the deployment request will be rejected._ _2. Applications Proxy Server_ The PhariaOS Applications Proxy Server is available to fulfill the usecases consumption. The applications proxy can be accessed at https://pharia-os-applications.product.pharia.com. Requests to the proxy are redirected to the usecases by providing the usecase (application) UUID as a URL path parameter, which is **required**. > The incoming request endpoint to the proxy server is the redirected endpoint to the usecase: > `https://pharia-os-applications.product.pharia.com/{applicationId}/summarization -> $internal_use_case_URL/summarization` **Expected Responses** A valid request and resource path will return the expected resource in the response. If the request path does not include the usecase (application) UUID, one of two responses is expected: * If the request path contains only a single part, the response is `BadRequest (400)`. * If the request path contains multiple parts, the response is `BadGateway (502)`, as the proxy is unable to validate our route the request to any usecase (application). **Examples** 1. Sending a `POST` request to the proxy server. The request is targeted to the usecase `execute` endpoint. ```sh curl --request POST \ --url https://pharia-os-applications.product.pharia.com/{applicationId}/execute \ --header 'Content-Type: application/json' \ --data '{ "question": "hello" }' ``` 2. Sending a `GET` request to the proxy server. The request is targeted to the usecase `health` endpoint. ```sh curl --request GET \ --url https://pharia-os-applications.product.pharia.com/{applicationId}/health ``` 3. Sending a `GET` request for the user interface. The request is targeted to the usecase `ui` endpoint. ```sh curl --request GET \ --url https://pharia-os-applications.product.pharia.com/{applicationId}/ui/assets/usecase.js ``` **Undeployment** Once the usecase has fullfilled the purposes and no longer needs to run and consume resources in your K8s cluster, the API provides an endpoint to undeploy the usecase. **Deleting usecases** A usecase may be deleted on request only if it is not currently **active** (that is: deployed, deploying, or undeploying). Deletion cleans the usecase and all associated records from the database.