设计RESTful API时,依赖其他资源的资源应该被建模为子URI,还是它们只是相互引用?
例如,假设门总是依赖于房屋,则
/house/73/door/1
或者/house/73
/door/1044
在哪里,house和door彼此包含引用关系?
我发现大多数RESTful API都比较平坦,因此我会珍视任何具有更复杂关系依赖性的API。
谢谢。
设计RESTful API时,依赖其他资源的资源应该被建模为子URI,还是它们只是相互引用?
例如,假设门总是依赖于房屋,则
/house/73/door/1
或者/house/73
/door/1044
在哪里,house和door彼此包含引用关系?
我发现大多数RESTful API都比较平坦,因此我会珍视任何具有更复杂关系依赖性的API。
谢谢。
请记住,URI只是服务器的实现细节。如果可以将它们建模为扁平资源,则应该这样做。这将使服务器更容易处理它们。
如果门的标识符在所有房屋中不是唯一的,则您的服务器将需要知道房屋,因此您需要在URI中包含房屋信息。
资源之间的关系应该通过返回表示中的链接进行建模。例如,您的房子表示可能应该包含指向该房子中所有门资源的链接。我建议尽量避免使用URL结构作为某个领域的含义。
只有在需要唯一标识资源时才使用层次结构。
door
的生命周期严格受到house
生命周期的限制),则使用子资源。
我并不建议画出UML图! 但记住这种区别确实有所帮助。(您还可以通过将子资源建模为指向真实资源的重定向来建模聚合情况;重定向是符合REST规范的。然而,我实际上不喜欢这样做;我更喜欢使任何关系明确,并尽量减少重定向数量。)
73
是数据库中的主键,你将无法轻松地合并数据库... - mogsie