我开始制作一个可以接收" route ";为json。这就是"路线"。它本身将作为一个字符串传递给服务器，包含在json字符串中。我想使用RESTful的标准方式来编写路由，以便以后更容易调试。但是，如下例所示:
contact 'get all contacts
contact/:id 'get the contact by id
Ugly areas:
contact/:id/jobs 'get the contact and all jobs assigned to contact
contact/:id/jobs/filter 'get the contact and all jobs assigned to contact,
'where those jobs meet a certain criteria (filter)
现在我可以避免在"job "通过在"/job"上设置CRUD路由，我将这样做。但是如果我想限制返回的工作岗位;对于上述特定的联系人，是否有一种方法来表示该查询而不构成新的约定?
就rest式架构而言，实际上，您所拥有的是好的。更严格的RESTful模式可能是这样的:
/jobs?contact_id=73284
/jobs?contact_id=73284&completed=1
其中73284是联系人的唯一ID, completed=1表示过滤器。
理解严格的RESTful原则是有用的，但在实践中不可能100%遵守。
一般来说，模式是:
METHOD:/resource/represention?any=query&string=you&want=here
或
METHOD:/resource?any=query&string=you&want=here
其中METHOD为GET、PUT、POST、PATCH、DELETE。resource是一类事物(思考表名)，representation是一个特定的事物(思考表行)，查询参数就像SQL中的WHERE子句一样。
在我看来，尝试使用query, restful对我来说大多意味着有意义
contact/:id/jobs =>contact/:id?populate=jobs//如果你想要一个联系人与工作，这意味着你仍然需要一个联系人，只是一些额外的信息
contact/:id/jobs/filter =>contact/:id?populate=jobs&jobs[xx]=xx过滤器也意味着额外的限制
/jobs?contact_id=xx这意味着你想要的工作列表，有一些额外的限制
REST并不关心您为资源标识符使用的拼写约定。只要你的拼写与RFC 3986描述的生成规则一致，你就可以了。
如果你有很多类似的资源，使用URI模板和变量扩展来定义你的标识符族是很方便的。它允许客户端使用通用库来构造您的标识符，并允许您选择使用通用库从每个请求的目标URI中解析信息。
除了一些纯粹的机械问题(例如:使用适当的转义序列)之外，您是否在查询中使用变量展开，或在路径段中使用变量展开，或在每个路径段中多次使用变量展开，或其他任何内容都无关紧要。
需要考虑权衡——路径段与相对分辨率结合得很好;application/x-www-form-urlencoded键值对可以很好地与HTML表单结合使用。
除此之外，机器不关心。因此，选择任何能让你关心的人更容易理解的拼写。