Breeze 微风与RESTfulWebAPI

问题：

当我需要在WebAPI中为每个实体实现自己的POST/PUT/GET端点时，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
}

Breeze似乎要求端点更加简单（无论是好是坏）——只需要一堆get和一个SaveChanges-POST端点

---

这让我想到Breeze通过一个web客户端实现了快速开发，好吧，Breeze。。。但是一旦你有了匿名客户机，你就必须强迫他们加入你在客户机中创建的任何breeze接口约定，这似乎违背了RESTful API设计的目的。是这样吗？

Breeze首先是一个客户端JavaScript框架。如果您没有在客户端上使用Breeze，那么Breeze.WebApi的好处仅限于

• 增强的OData查询支持（$select和$expand支持，扩展$orderby）
• 保存截取点（beforeSaveEntity和beforeSaveEntities事件）
• 保存结果处理（更新的实体键、并发列）
• 元数据提取和序列化

正如您所猜测的，Breeze在CRUD操作方面有着与REST不同的理念

Breeze是为那些希望在单个事务中使用C/U/D转换多种不同类型资源的客户而设计的。这允许用户以复杂的方式操作数据，而无需点击服务器，然后在准备就绪时保存更改。例如，可以创建一个新的

订单

，将两个

OrderLineItem

从一个

订单

移动到另一个

订单，删除第三个
OrderLineItem
，修改第四个订单的数量，然后
保存更改（）。Breeze甚至支持使用localStorage在与服务器完全断开连接的情况下工作。重新连接后，可以保存所有更改

REST的设计目的是对其进行操作。必须立即对服务器执行每个C/U/D操作，以便对响应代码进行操作。它适用于具有简单更新需求的应用程序，但不适用于数据输入应用程序。然而，它们充其量也很麻烦

话虽如此，您的服务器端Breeze API并不局限于您在Todos示例中看到的内容。Breeze支持，这允许您为不同的操作使用不同的端点。您还可以使用来确保您的保存捆绑包只包含它应该包含的类型。当然，没有什么可以阻止您在服务器上公开这两个API，并让它们都由同一个持久层提供

如果你必须在两者之间做出选择，你应该从你的用户开始。真正的用户（不是开发人员）不关心REST，他们关心应用程序能做什么。最终，REST为应用程序提供了HTTP的所有语义，Breeze为应用程序提供了关系数据库或对象数据库的所有语义。向用户公开哪一个应该取决于您需要支持的用例。
写得很好，答案很完整！
GET /api/todo/1
PUT /api/todo
POST /api/todo