关于为API寻址REST资源的建议

Question

我是一个新的REST转换器，我正在尝试设计我的第一个RESTful（希望）api，这是我关于寻址资源的问题

首先注意一些事项：

• 此处描述的数据是3d渲染 工作
• 用户（图形公司）有多个项目。
• 项目有多个渲染作业。
• 渲染作业有多个框架。
• 在数据中强制执行层次结构（1个渲染作业 属于一个项目，属于一个用户）

如何命名我的资源......？

https:/api.myrenderjobsite.com/

/users/graphicscompany/projects
/users/graphicscompany/projects/112233
/users/graphicscompany/projects/112233/renders/
/users/graphicscompany/projects/112233/renders/889900
/users/graphicscompany/projects/112233/renders/889900/frames/0004

OR渲染的缩短地址？

/users/graphicscompany/renders/889900
/users/graphicscompany/renders/889900/frames/0004

或者我应该尽可能地缩短（甚至更多）地址，在不需要时省略用户......？

/projects/112233/
/renders/889900/
/renders/889900/frames/0004

谢谢！

Answer 1

不要在URL方面考虑你的api，而是尝试更像页面和链接

这些页面之间。

请考虑以下事项：

为用户创建资源是否合理？你有10,20或50个用户吗？或者你有10,000个用户？如果是后者那么显然创建一个代表所有用户的单一资源，当你对它进行GET时可能不会很好。

用户列表是否是合理的根URL？即进入您服务的入口点。属于GraphicsCompany的项目列表是否应该是一个单独的资源，还是应该只嵌入到Graphics Company资源中？您可以对存在的每对1对多关系提出相同的问题。即使您决定将项目列表合并到GraphicsCompany资源中，您仍然可能希望存在一个简单的资源，以便能够对其进行POST以便为该公司创建新项目。

使用这种方法，您应该能够很好地了解API中的大多数资源以及它们的连接方式，而无需担心您的网址是什么样的。实际上，如果您正确设计，那么您正确的任何客户端应用程序都不需要了解您创建的URL。关注URL的系统的唯一部分是您的服务器，以便它可以将请求分派给正确的控制器。

您需要问自己的另一个重要问题是您将使用哪种媒体类型来获取这些资源。有多少不同的客户需要访问这些资源？你在写客户，还是别人？您是否应该尝试重用现有标准，如XHTML和类/微格式？你能把大部分信息都压缩成Atom吗？也许Atom有一些像GDATA这样的额外名称空间吗？或者这只是在内部使用，所以你可以创建自己的媒体类型，如application / vnd.YourCompany.Project + xml，application / vnd.YourCompany.Render + xml等。

在设计REST api时需要考虑很多事情，不要挂断你的URL看起来像什么，你应该尽量避免做“按URL设计”。

Answer 2

就个人而言，我不会试图过多地挤压路径，也就是说，一些冗余信息对于快速查看资源是什么以及将来的扩展都有帮助。 一般来说，用户不会输入路径，所以详细程度并不是那么糟糕。