0

我正在设计一个系统，该系统使用asp.net webapi来提供许多 jquery 网格控件使用的数据。页面加载后，网格会回调数据。我有一个用户表和一个项目表。在它们之间是一个存储多对多关系的成员表。

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

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

4

2 回答 2

0

现代标准是一种非常简单的方法，称为REST只需仔细阅读并实施它。

于 2013-01-31T01:21:17.857 回答
0

就像 Ph0en1x 所说，REST 是 Web 服务的新趋势。看起来您已经在一些建议的路线上走在了正确的轨道上。我在工作中一直在做一些 REST 设计，这里有一些事情需要考虑：

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

  2. 把事情简单化。一个主要目标应该是可发现性。我的意思是，如果我是您系统的普通用户，并且我知道有用户和项目，也许还有另一个名为“目标”的实体......我想猜测 /goal 并获得目标列表。这让用户非常高兴。他们需要参考的文档越少越好。

  3. 避免将大量垃圾附加到查询字符串中。我们目前在我的工作中遭受这种痛苦。一旦 API 获得一些关注，用户可能需要更细粒度的控制。注意不要把 URL 变成乱七八糟的东西。像 /user?sort=asc&limit=5&filter=...&projectid=...

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

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

这些天我知道我在 REST API 中想要什么，那就是直觉、可发现性、简单性，以及避免不断挖掘复杂的文档。

于 2013-01-31T03:46:15.917 回答