面向数据检索的端点设计面向ASP.NET webapi

时间：2013-01-30 16:35:08

标签： asp.net api

我正在设计一个使用 asp.net webapi 来提供由许多jquery网格控件使用的数据的系统。页面加载后，网格会回调数据。我有一个User表和一个Project表。在这些之间是一个存在多对多关系的Membership表。

User
userID
Username
Email

Project
projectID
name
code

Membership
membershipID
projectID
userID

我的问题是将这些数据和关系描述为webapi的最佳方法是什么？

我有以下路线

GET: user  // gets all users
GET: user/{id}  // gets a single user
GET: project
GET: project/{id}

我认为一种方法是：

GET: user/{id}/projects  // gets all the projects for a given user
GET: project/{id}/users  // gets all the users for a given project

我不确定路由和控制器的配置应该是什么样的，或者即使这是正确的方法。

2 个答案:

答案 0 :(得分：0)

现代标准是一种非常简单的方法REST请仔细阅读并实施。

答案 1 :(得分：0)

与Ph0en1x一样，REST是Web服务的新趋势。看起来您已经使用了一些建议的路线。我在工作中一直在做一些REST设计，这里有一些需要考虑的事情：

  1. 与您的路线保持一致。您已经这样做了，但请注意其他开发人员何时开始编写路由。用户需要使用API​​的一致路线。

  2. 保持简单。一个主要目标应该是可发现性。我的意思是，如果我是您系统的常规用户，并且我知道有用户和项目，可能还有另一个称为“目标”的实体...我想猜/目标并获得目标列表。这使用户非常高兴。他们引用文档越少越好。

  3. 避免在查询字符串中附加大量垃圾。我们目前在工作中受苦。一旦API获得一些牵引力，用户可能需要更细粒度的控制。小心不要将URL变成凌乱的东西。像/ user？sort = asc＆amp; limit = 5＆amp; filter = ...＆amp; projectid = ...

  4. 保持网址简洁明了。我再次喜欢这个设计良好的API。我很容易记住像http://api.twitter.com这样的东西。像http://www.mylongdomainnamethatishardtospell.com/api/v1/api/user_entity/user这样的东西......更难记住，令人沮丧。

  5. 仅仅因为在Web上使用REST API并不意味着它与客户端唯一代码中的常规方法完全不同。我已经读过任何方法应该有不超过3个参数的论点。这个想法类似于（3）。如果您发现自己想要扩展，请考虑添加更多方法/路由，而不是更多参数。

    6. 我现在知道自己在REST API中想要什么，这是直觉，可发现性，简单性以及避免不断浏览复杂的文档。

相关问题
最新问题