generator: emit REST-style aliases (.create / .update / .register) for .set #25

New issue

Open

opened 2026-04-19 13:03:54 +00:00 by timur · 0 comments

timur commented

2026-04-19 13:03:54 +00:00

Owner

Problem

The OSIS generator (crates/generator/src/rust/rust_osis.rs:736-768) emits method names using only:

{lowercase_typename}.new | .get | .set | .delete | .list | .find
+ per-service custom methods

UI developers and REST-trained clients naturally reach for contact.create, context.register, task.update, etc. These fail with -32601 Method not found, which is confusing because the CRUD operation does exist under .set.

Real example: hero_osis issue #24 — hero_os UI sends context.register and task.create; both fail even though context.set and task.set are registered.

Proposal

Have the generator emit REST-style aliases alongside the existing names:

Current	Alias(es)
`{type}.set` (no existing SID)	`{type}.create`
`{type}.set` (existing SID)	`{type}.update`
`{type}.new`	(keep as is — builder/initializer)
`{type}.delete`	`{type}.remove` (optional)

Each alias is a thin match arm that dispatches to the same handler. Zero new logic in the handlers themselves.

Why not rename callers instead

Three reasons:

Callers are spread across multiple repos (hero_os, hero_biz, hero_osis_ui, etc.) — a rename is a cross-cutting migration.
REST-style names are what external SDK users will reach for first. Making them work is a 5-minute onramp win.
.set semantically covers both create and update. Splitting to .create/.update at the API surface is clearer for clients.

Scope

Modify rust_osis.rs to emit alias match arms in handle_rpc
Update to_openrpc to list both canonical and alias names
Regenerate downstream services and verify (hero_osis first)
Add note to the getting-started guide

hero_osis #24 — missing context.* / task.* RPC methods (user-facing symptom)
Issue #12 — generator naming collision (different but related area of the generator)

## Problem The OSIS generator (`crates/generator/src/rust/rust_osis.rs:736-768`) emits method names using only: ``` {lowercase_typename}.new | .get | .set | .delete | .list | .find + per-service custom methods ``` UI developers and REST-trained clients naturally reach for `contact.create`, `context.register`, `task.update`, etc. These fail with `-32601 Method not found`, which is confusing because the CRUD operation *does* exist under `.set`. Real example: hero_osis issue #24 — hero_os UI sends `context.register` and `task.create`; both fail even though `context.set` and `task.set` are registered. ## Proposal Have the generator emit REST-style aliases alongside the existing names: | Current | Alias(es) | |---|---| | `{type}.set` (no existing SID) | `{type}.create` | | `{type}.set` (existing SID) | `{type}.update` | | `{type}.new` | *(keep as is — builder/initializer)* | | `{type}.delete` | `{type}.remove` (optional) | Each alias is a thin match arm that dispatches to the same handler. Zero new logic in the handlers themselves. ## Why not rename callers instead Three reasons: 1. Callers are spread across multiple repos (hero_os, hero_biz, hero_osis_ui, etc.) — a rename is a cross-cutting migration. 2. REST-style names are what external SDK users will reach for first. Making them work is a 5-minute onramp win. 3. `.set` semantically covers both create and update. Splitting to `.create`/`.update` at the API surface is clearer for clients. ## Scope - [ ] Modify `rust_osis.rs` to emit alias match arms in `handle_rpc` - [ ] Update `to_openrpc` to list both canonical and alias names - [ ] Regenerate downstream services and verify (`hero_osis` first) - [ ] Add note to the getting-started guide ## Related - hero_osis #24 — missing `context.*` / `task.*` RPC methods (user-facing symptom) - Issue #12 — generator naming collision (different but related area of the generator)