Question

在设计RESTFul的URI时，对于用C＃编写的ASP.Net Web API应用程序，我发现自己陷入了困境，最佳实践是什么。

采用以下伪代码。

public class File{
 public int ID {get;set;}
 public string Name {get;set;
}

public class X {
 public int ID {get;set;}
 public string Name {get;set;}
 public List<File> Files {get;set;}
}

public class Y  {
 public int ID {get;set;}
 public string Name {get;set;}
 public List<File> Files {get;set;}
}

public class Z  {
 public int ID {get;set;}
 public string Name {get;set;}
 public List<File> Files {get;set;}
}

现在，如果我想要一个特定的文件，我会称之为：

/api/Files/{ID}

现在，如果我想要与其他资源相关的文件，我是否要创建路径：

/api/X/{xID}/Files
/api/Y/{yID}/Files
/api/Z/{zID}/Files

或者我也会这样做：

/api/Files/X/{xID}
/api/Files/Y/{yID}
/api/Files/Z/{zID}

在维护方面，后一种选择似乎更合适;与文件有关的任何内容都包含在同一个控制器中。

虽然前一种选择对我来说似乎更明确，但不知何故，虽然意味着在整个控制器中传播类似的呼叫

或者，是否有不同的解决方法？

Answer 1

我认为这是使用json引用的一种情况

http://json-spec.readthedocs.org/en/latest/reference.html

我不确定这个例子是否特别清楚，但是你必须提供/ Files / fileId接口然后在你的X / Y / Z对象中而不是包含你引用它的文件

{
    "Files" : [{"$ref" : "/file/myFileId"}]
}

如果您想提供一个返回多个未分组资源的界面，恭喜您已经达到了REST的限制，请使用POST

----重新评论：

详细说明＆＃39;使用POST＆＃39;

RESTful方法是使用GET来获取＆＃39;但是，当你必须传递多个ID，即GET文件？id = 1＆amp; id = 2＆amp; id = 3 .....时，你会遇到网址上的长度限制。这会强制你使用POST文件BODY id = 1＆amp; id = 2＆amp; id = 3 .....（或者更可能是一些json请求结构）关于堆栈溢出的各种方法有几个类似的问题

Answer 2

有许多指南可以解释如何设计API的最佳实践。最终，设计师需要提供一个适合开发人员的API。

在这种情况下，您谈论的是两个不同的端点：（1）Files端点，以及（2）包含文件的其他资源（让我们称之为Folders）。

一般来说，您的网址应包含API的版本（例如“v1”）和资源端点（例如“文件”）。因此，您的网址将形成如下：

1. /api/v1/files
2. /api/v1/folders

对于查询，您需要确保遵守一些标准查询字符串参数（例如/api/v1/files?id=blah），而不是使用斜杠标记或其他字符分隔查询参数。

对于另一个端点（folders），在初始get中包含文件（或至少是标识符）可能是有意义的，或者要求呼叫者询问是否有意义在提供此信息之前，对于特定的folder。

通过要求开发人员在files中获取folder时找出复杂的网址，将对象拆分是不合适的。如果在查询files时不希望包含folder，那么最好不要关闭关系并允许客户端查询给定files内的folder {1}}使用files端点上的查询字符串语法。

一些有用的链接：

哪种API路由设计符合最佳实践？

2 个答案: