microsoft / microsoft/typespec

Move resource abstraction to `@cadl-lang/resource` (aka resource reform)

Open
#638 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
Java
Stars
5.9k
Forks
394
Avg merge
1d 23h
Merged PRs (30d)
104

Description

Right now, the `resource` abstraction is mixed in with the Rest library, but to my eyes, resources are a protocol-agnostic pattern. If the resource abstraction uses no REST terminology it should be possible to emit some canonical resource pattern in both gRPC and Rest for example.

Likewise, this feels like the natural place to "own" the visibility semantics - the precise set of flags supported, and functionality to apply those flags to model types for use in emitters. If we use enums and enum references, this allows other resource abstractions (or database ORM generators or whatever) to establish their own set of visibility flags without conflict.

With this, a simple resource that supports emitting to gRPC and Rest might look like:

```
import "@cadl-lang/resource";
import "@cadl-lang/http";
import "@cadl-lang/grpc";

@serviceTitle("Widget Service")
namespace DemoService;

using Cadl.Http;
using Cadl.Resource;
using Cadl.gRPC;

model Widget {
@field(1) @key id: string;
@field(16) weight: int32;
@field(17) color: "red" | "blue";
@field(18) @visibility(Visibility.Create) password: string;
}

@error
model Error {
@field(1) code: int32;
@field(2) message: string;
}

interface WidgetService extends Resource.ResourceOperations {
@get @route("customGet") customGet(): Widget;
}
```

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.