asp.net-mvc - 具有复杂操作(动词)的 RESTful Web 服务

Question

我正在尝试构建一个 Web 应用程序，其中后端是一个完整的 RESTful Web 服务。 IE。模型(业务逻辑)将完全可以通过 HTTP 访问。例如:

GET    /api/users/
GET    /api/users/1
POST   /api/users
PUT    /api/users/1
DELETE /api/users/1

提供更多非 CRUD 方法(动词/操作)的正确方法是什么？这是否被认为更像是一个 RPC-api 域？如何正确设计 RPC api 以在 RESTful api 之上运行？

例如，我如何优雅地为用户实现忘记密码的方法。

POST (?) /api/users/1/forgot

应用程序( Controller / View )然后将使用 https 请求(类似 HMVC)来访问模型和方法。什么是最好的身份验证？ OAuth、HTTP 上的基本身份验证？

虽然这是以后可扩展性的“最佳实践”，但我是否过度设计了这项任务？是否最好只遵循典型的 MVC 模型并提供非常基本的 API？

这个问题主要受到 ASP.NET 的 MVC 4 (WebAPI) 和 NodeJS 模块 https://github.com/marak/webservice.js 的启发。

提前致谢

Answer 1

我最近开始学习 REST，在开发新的 Web 服务时，我认为考虑它是正确的做法。

您对自定义动词的假设是正确的。 REST 承认某些操作需要以不同的方式处理，并且自定义动词不会违反要求。与服务器通信时应使用POST，但动词通常写在 imperative 中。 。我可能会使用提醒或类似的东西，而不是忘记。也就是说，您应该给出要做什么的指示，而不是在没有明确表明您期望结果的情况下描述发生的事情。

此外，构建服务的首选方法是将api包含到域名中，并将其从路径中删除。我会像这样写你的特定示例:

POST /users/1/remind HTTP/1.1
Host: api.myservice.example.com

REST 中的 session 处理有点棘手。最干净的方法可能是使用基本访问身份验证对每个请求进行用户名和密码身份验证。不过，我相信很少有人这样做。您应该阅读这个问题(及其接受的答案):OAuth's tokens and sessions in REST

编辑: 在您的示例中，我还会删除 GET 请求中的尾部正斜杠。如果服务确实是 RESTful，则不应从 /users/ 和 /users 访问该资源。一项特定资源应该有且仅有一个指向它的 URL。带有尾部斜杠的 URL 实际上与没有尾部斜杠的 URL 不同。 REST 提倡放弃它，并且 RESTful Web 服务不应同时接受两者(在 GET 的情况下意味着以 200 OK 进行响应)，尽管它可能会从一个重定向到另一个。否则，可能会导致对正确 URL 的混淆、重复缓存、哭泣和切齿。 :)

编辑 2: 在 Richardson & Ruby 的 RESTful Web Services 中，不鼓励您将新动词放入路径中。相反，您可以附加类似 ?_method=remind 的内容。选择哪一个取决于您，但请记住，您不不应该使用 GET 处理这些请求，无论如何选择。 GET 不得更改资源，并且如果用户在历史记录中来回浏览，则不应产生副作用。否则，您可能会多次重新发送密码。请改用 POST。