复杂动作（动词）的REST风格的Web服务

我试图构建一个Web应用程序，其中后端是一个完整的REST风格的Web服务。即模型（业务逻辑）将通过HTTP完全访问。例如：复杂动作（动词）的REST风格的Web服务

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

应用程序（控制器/视图）然后使用HTTPS请求（HMVC等）来访问模型和方法。什么是最好的认证？ OAuth，基于HTTP的基本身份验证？

尽管这对于后来的可伸缩性来说是“最佳实践”，但我是否在完成这项任务？遵循典型的MVC模型并提供非常基本的API最好吗？

这个问题已经通过ASP.NET的MVC 4（的WebAPI）和模块的NodeJS大多了启发提前https://github.com/marak/webservice.js

感谢

来源

2012-05-13 user1236971

我最近开始学习REST和开发新的Web服务，我认为当你在做正确的事情来考虑它。

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

此外，构建服务的首选方法是将api包含到域名中，并将其从路径中删除。我会写你的具体的例子是这样的：在REST

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

会话处理是有点棘手。最简单的做法可能是使用基本访问身份验证，在每个请求上使用用户名和密码进行身份验证。不过，我相信很少这样做。你应该阅读这个问题（和它的接受的答案）：OAuth's tokens and sessions in REST

编辑：我还降在你的榜样GET请求后正斜杠。如果服务是真正的RESTful，那么资源不应该从/users/和/users两者都可访问。一个特定的资源应该只有一个URL指向它。带有斜线的URL实际上与没有的斜线不同。 REST促进删除它，并且一个REST风格的Web服务不应该同时接受（在GET的情况下意味着以200 OK响应），尽管它可以从一个到另一个重定向。否则，可能会导致对正确的URL，重复的缓存，哭泣和咬牙切齿的混淆。:)

编辑2：在REST Web服务理查森&红宝石你从把动词的路径气馁。相反，你可以附加类似?_method=remind的东西。这取决于你选择哪一个，但请记住你是而不是应该用GET,来处理这些请求，不管你选择什么。 A GET不得更改资源，并且如果用户在历史记录中来回浏览，则不应导致副作用。否则，您可能会多次重新发送密码。改为使用POST。

来源

2012-05-20 07:45:39

感谢您的回复安德斯。你认为最好是使用典型的MVC方法构建我的应用程序（模型直接与数据库通信），然后担心后续制作api.mysite.com？然后将模型修改为直接与api通信而不是数据库。将模型抽象出来可能是理想的，这样在模型中不会处理会话/认证，是正确的吗？ – user1236971

@ user1236971我不是专家，但我看到它的方式：单独开发模型听起来有点像矛盾。您的模型应该以结构化的方式提供数据，尽可能多地隐藏底层实现。它还应该处理一些基本的安全措施，并隐藏不应该暴露的内容。例如，您应该能够更改或验证密码，但不会检索它（即使是散列）。这或多或少正是API应该做的，而且你不应该复制你的代码。您的模型*是*您的API，尽管您可能会跳过JSON转换。 –

@ user1236971噢，顺便说一下，我不确定你抽象模型的意思，以便它们不处理认证。你打算怎么做？我会试着实现这个模型，以便视图或控制器中的错误永远不会破坏数据，这可能涉及到执行一些权限检查。但正如我所说的，会话管理非常棘手，我不知道最佳实践。我遇到同样的问题。 –

复杂动作（动词）的REST风格的Web服务

回答

相关问题