嵌套REST路由 [英] Nested REST Routing

问题描述

简单的情况：我有一个服务器上有数千张图片。我想创建一个安静的业务层，这将允许我添加标签（类别）到每个图片。这很简单。我还想获得匹配单个标签的图片列表。这也很简单。但现在我还想创建一个接受标签列表的方法，它将只返回与所有这些标签匹配的图片。这有点复杂，但我仍然可以这样做。

然而问题是这样的。说，我的休息服务在pictures.example.com，我想要能够进行以下调用：

Simple situation: I have a server with thousands of pictures on it. I want to create a restful business layer which will allow me to add tags (categories) to each picture. That's simple. I also want to get lists of pictures that match a single tag. That's simple too. But now I also want to create a method that accepts a list of tags and which will return only pictures that match all these tags. That's a bit more complex, but I can still do that.
The problem is this, however. Say, my rest service is at pictures.example.com, I want to be able to make the following calls:

• pictures.example。 com / Image / {ID} - 应返回特定图片


• pictures.example.com/Images - 应返回图片ID列表。


• pictures.example.com/Images/ {TAG} - 应返回此标签的图片ID列表。


• pictures.example.com/Images/ {TAG} / {TAG} - 应返回包含这些标签的图片ID列表。


• pictures.example.com/Images/ {TAG} / {TAG} / {TAG} - 应返回图片ID列表


• pictures.example.com/Images/ {TAG} / {TAG} / {TAG} / {TAG} / {TAG} - 应返回图片ID列表


• etcetera ...

• pictures.example.com/Image/{ID} - Should return a specific image
• pictures.example.com/Images - Should return a list of image IDs.
• pictures.example.com/Images/{TAG} - Should return a list of image IDs with this tag.
• pictures.example.com/Images/{TAG}/{TAG} - Should return a list of image IDs with these tags.
• pictures.example.com/Images/{TAG}/{TAG}/{TAG} - Should return a list of image IDs with these tags.
• pictures.example.com/Images/{TAG}/{TAG}/{TAG}/{TAG}/{TAG} - Should return a list of image IDs with these tags.
• etcetera...

RESTful Web服务项目，将允许我嵌套这样的标签，仍然能够阅读所有？没有对标签数量的任何限制，虽然URL长度将是一个限制。我可能想在一个选择中最多有30个标签，我不想设置30个不同的路由东西，使其工作。我想要一个路由的东西，在技术上允许无限的标签。

So, how do I set up a RESTful web service projects that will allow me to nest tags like this and still be able to read them all? Without any limitations for the number of tags, although the URL length would be a limit. I might want to have up to 30 tags in a selection and I don't want to set up 30 different routing thingies to get it to work. I want one routing thingie that could technically allow unlimited tags.

是的，我知道可以有其他方法来回发送这样的列表。更好的甚至，但我想知道如果这是可能的。如果它很容易创建。所以URL不能与上面的例子不同。

必须简单，我想。只是不能提出一个好的解决方案...

Yes, I know there could be other ways to send such a list back and forth. Better even, but I want to know if this is possible. And if it's easy to create. So the URL cannot be different from above examples.
Must be simple, I think. Just can't come up with a good solution...

推荐答案

您选择的URL结构应该基于任何容易实现与您的Web框架。我会期望像：

The URL structure you choose should be based on whatever is easy to implement with your web framework. I would expect something like:

http://pictures.example.com/images?tags=tag1,tag2,tag3,tag4

在服务器上更容易处理，我看不到路径段方法，你有麻烦。

Is going to be much easier to handle on the server, and I can see no advantage to the path segment approach that you are having trouble with.

这篇关于嵌套REST路由的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！