# Add a REST API to a Spring Boot App from a Linear Issue

Yes. An agent picks up the Linear issue, adds JSON owner endpoints under /api/owners to your Spring Boot app, runs verify and opens a pull request.

[Run this on Rush](https://cloud.getrush.ai/run/add-rest-api/spring-boot/), in a Project that has your repository.

## What the agent does

The agent starts from the Linear issue and the repository in its own sandbox, and maps how owners are exposed today. In a codebase like spring-projects/spring-petclinic (Spring Boot 4.1.0 parent, Java 17, Maven wrapper `./mvnw`), `OwnerController` is an MVC `@Controller` that serves Thymeleaf under `/owners`, `/owners/find` and `/owners/{ownerId}`, backed by `OwnerRepository` (`JpaRepository<Owner, Integer>` with `findByLastNameStartingWith`). JSON today is limited: `VetController` exposes a `@ResponseBody` vet list, not owners. There is no `/api/owners` resource.

It adds a dedicated REST controller (for example `OwnerRestController`) mapped under `/api/owners` for listing, reading and creating owners with their pets, reusing `Owner`, pet associations and bean validation already on the domain. Validation failures return Spring's problem details (`application/problem+json`) rather than HTML form errors. It keeps the existing Thymeleaf owner flows untouched so the browser UI and the API do not fight over the same request mappings.

Tests go under `src/test/java/.../owner/` beside `OwnerControllerTests` and `OwnerTests`, using MockMvc or `@WebMvcTest`/`@SpringBootTest` in the style the project already uses. Cases cover list and get JSON shapes, a successful create, and a validation error that answers a problem detail with field errors. The agent runs `./mvnw verify`, which is the project's full Maven lifecycle including tests.

Last, it opens a pull request that links the Linear issue, lists the new controller, any DTO or exception-handler wiring and the tests, and quotes the verify command result from the sandbox.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "A Linear issue labeled agent says: \"Add a REST API to a Spring Boot App. Add JSON endpoints under /api/owners for listing, reading and creating owners with their pets, with validation errors returned as problem details.\" Do the work in this repository, add tests for it, run ./mvnw verify, and open a pull request that links back to the issue.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    }
  ]
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

What comes back is a pull request on its own branch. The description states that owners were HTML-only through `OwnerController` while vets already had a JSON peek, then shows the new `/api/owners` endpoints and problem-detail error bodies. The Linear issue is linked.

The transcript keeps `./mvnw verify` (downloads, compile, tests) with full output. PetClinic's existing unit and integration tests stay part of that run, so a broken Owner mapping fails the same way CI would.

Before merging, a reviewer checks content types, that create validates required owner fields, that pets nest as the API promises, that Thymeleaf `/owners` routes still render, and that the new tests fail if the REST controller is missing.

## Run it on every Linear issue labelled agent

In the console, an automation with a `linear` trigger on `linear.issue.labeled` and the label `agent` starts one run per labelled issue, with the issue as its context, in the Project's repository. Changes made by an app integration never fire it, so the agent's own updates do not start new runs.

From your own server, the same run is one `POST /o/{org}/sessions` per issue: put the repository in `resources`, and add the issue's `https://linear.app/<workspace>/issue/<ID>` URL there too to have Rush read it through your Linear connection into the prompt. A webhook on the API key posts `run.completed` or `run.failed` when the turn finishes, with the `session_url` to read the result.

## Why run it on Rush?

PetClinic's verify step pulls dependencies and runs a modest but real suite, including database-backed integration tests. In a Rush sandbox that work happens on an isolated disk with the project's `mvnw`, so nobody's laptop JDK or local MySQL/Postgres profile is required for the agent to finish.

Labelling the issue in Linear yields a PR whose transcript shows the agent reading `OwnerController` and `OwnerRepository` before adding a parallel REST surface. Multiple Spring issues can run concurrently, each in its own sandbox and branch, up to the key's `max_concurrent` limit.

## Frequently asked questions

### Does it replace the Thymeleaf owner pages?

No. The issue asks for JSON under `/api/owners`. The existing `/owners` MVC controller stays; the agent adds a separate REST mapping so the browser UI keeps working.

### Maven or Gradle?

Whatever the repo's canonical wrapper is. PetClinic ships both; the prompt pins `./mvnw verify`, so the agent uses the Maven wrapper unless your Project prompt says otherwise.

### What does a validation error look like?

A problem details response (`application/problem+json`) with the failing fields, not a Thymeleaf form re-render. Tests assert status and content type for that path.

### Will it expose every Owner field?

It mirrors what create/edit already need (name, address, city, telephone, pets) and says in the PR if it omitted internal fields. Reviewers can tighten the DTO before merge.