9

質問:

WebAPI のエンティティごとに独自の POST/PUT/GET エンドポイントを実装する必要がある場合、breeze はどのような価値を提供しますか?

バックグラウンド:

これは、サーバー側の Breeze コントローラーの一般的な実装のようです。

[BreezeController]
public class TodosController : ApiController {

    readonly EFContextProvider<TodosContext> _contextProvider =
        new EFContextProvider<TodosContext>();

    // ~/breeze/todos/Metadata
    [HttpGet]
    public string Metadata() {
        return _contextProvider.Metadata();
    }

    // ~/breeze/todos/Todos
    // ~/breeze/todos/Todos?$filter=IsArchived eq false&$orderby=CreatedAt
    [HttpGet]
    public IQueryable<TodoItem> Todos() {
        return _contextProvider.Context.Todos;
    }

    // ~/breeze/todos/SaveChanges
    [HttpPost]
    public SaveResult SaveChanges(JObject saveBundle) {
        return _contextProvider.SaveChanges(saveBundle);
    }

    // other miscellaneous actions of no interest to us here
}

私は、この時点までに次のようなエンドポイントを持つ RESTish API を構築している最中です。

GET /api/todo/1
PUT /api/todo
POST /api/todo

Breeze では、エンドポイントを (良くも悪くも) はるかに単純にする必要があるようです。GETS の束と SaveChanges POST エンドポイントだけです。

これにより、Breeze は 1 つの Web クライアントで迅速な開発を行うことができると思います。まあ、簡単ですが、匿名クライアントを作成したらすぐに、クライアントで作成した簡単なインターフェイス規則にそれらを強制する必要があります。これ、RESTful API 設計の目的に反しているようです。これは事実ですか?

4

1 に答える 1