fix: migrate API client to REST endpoints

[jaredmcqueen]

Summary

• migrate CLI requests from the legacy /trpc transport to Dokploy's REST endpoints under /api
• pass GET parameters through Axios so values are encoded correctly
• send POST bodies directly and return REST response payloads without the tRPC envelope
• add regression coverage for parameterized GET and POST requests

Root cause

The generated commands call apiGet and apiPost, but those helpers still used tRPC URLs and payload envelopes. Current Dokploy servers expose these procedures through REST endpoints, causing parameterized commands such as project one to fail with HTTP 400.

This incorporates and preserves the original commits from #40 by @OskarWiedeweg, then adds encoded query handling and regression tests.

Fixes #39.

Validation

• generated 544 commands from the current OpenAPI specification
• TypeScript build completed successfully
• all 20 tests passed
• Biome check passed for the changed client and tests
• verified project all and parameterized project one against a live Dokploy instance

[krishna2206]

Independent validation ✅

Checked out this branch and ran it against a live Dokploy server (v0.29.x) with a real API key.

On main, every parameterized GET query fails with Request failed with status code 400. With this branch the same commands succeed:

• application one --applicationId <id>: 400 → 200, returns the full application payload.
• No-argument queries (e.g. project all) keep working — no regression.

The REST migration is the correct root-cause fix: current Dokploy servers expose these procedures under /api, not /trpc. This also resolves #46 (same underlying cause as #39) — the { json: ... } superjson-wrapping workaround suggested there is unnecessary once requests go through the REST endpoints.

The client.test.ts REST regression tests added here pass locally. Would be great to see this merged. 🙏

[ambymon]

Independent verification against a live Dokploy v0.29.13 panel using @dokploy/cli 0.29.4 from npm (ids redacted):

project all      -> 200  (the only command that takes no params)
project one      -> 400
application one  -> 400
deployment all   -> 400
environment one  -> 400

So the breakage is every parameterized read, not just project one.

Raw requests isolate the cause — same procedure, three shapes:

GET /api/trpc/application.one?input={"applicationId":"<id>"}          -> 400   <- current apiGet
GET /api/trpc/application.one?input={"json":{"applicationId":"<id>"}} -> 200
GET /api/application.one?applicationId=<id>                           -> 200   <- this PR

Two details that support this PR's direction:

1. apiPost was never broken only because it already wraps payloads as { json: data }. That asymmetry with apiGet is the entire bug (also filed as GET (query) requests don't wrap input in {json: ...}, breaking every parameterized read against tRPC servers using the superjson transformer #46) — worth saying explicitly in the changelog, since from the outside it reads as "the server dropped tRPC support", which is not what happened.

2. The response envelope really does differ, and this PR handles it correctly:

GET /api/application.one       -> bare object: {appName, applicationId, applicationStatus, ...}
GET /api/trpc/application.one  -> {"result":{"data":{...}}}

So dropping response.data?.result?.data?.json ?? response.data is right for the REST route — whereas a minimal {json:…} fix on the tRPC route would have to keep it.

Scope caveat on my end: I verified the GET side live. I did not exercise the POST side against a real server (that panel is production), so client.post(/${endpoint}, data) is confirmed only against the documented REST contract (POST /api/application.deploy with {applicationId}), not by me calling it.