使用 MVC2 作为决定 URL 路径的 RESTful 服务
我正在创建一个应用程序，其中客户端功能调用各种服务来返回结果/内容等。目前，我有 3 个控制器，它们的操作运行良好。我想要决定的是如何管理列表内容，即在 2 个实例中，将出现下面概述的下拉数据的 JSON 列表：
在一个页面中，将有一个需要调用例如汽车列表的下拉列表使。一旦选择了品牌，另一次调用就会返回两个附加数组，例如汽车产品等。在另一页中，只有一个调用返回两个产品数组。共同的主题是它本质上是列表管理。
目前，我的控制器设置为： 现有会员 切换器 NewMember
Switcher 需要一个 CarMake 列表，然后关联调用以获取产品。 现有会员需要产品列表。
设置控制器/操作/id 的最佳方法是什么？
我尝试过各种选项：
- /Switcher/CarMakes
- /Switcher/CarProducts/7
- /ExistingMember/Products
还为简洁起见修改路线：
- /{controller}/List/{action}/{id}
- /Switcher/List/CarMakes
- /Switcher/ List/CarProducts/7
或移至专用列表控制器
- /List/CarMakes
- /List/CarProducts/7
- /List/Products
I am creating an application where client-side functionality calls various services to return results/content etc. At the moment, I have 3 controllers, with their actions which is working fine. What I'm trying to decide is how to manage list content, i.e. in 2 instances, there will be JSON lists of drop-down data outlined below:
In one page, there would be a dropdown that needs to call a list of e.g. Car Makes. Once selected a make, another call to then return two additional arrays of e.g. Car products etc. In another page, there is just one call to return two arrays of products. The common theme is that it is essentially list management.
At the moment, I have my controllers setup as:
ExistingMember
Switcher
NewMember
Switcher requires a list of CarMakes, and then associated call to get products.
ExistingMember requires a list of Products.
What is the best way to setup my Controller/Action/id?
I have toyed with various options:
- /Switcher/CarMakes
- /Switcher/CarProducts/7
- /ExistingMember/Products
Also modifying routes for brevity:
- /{controller}/List/{action}/{id}
- /Switcher/List/CarMakes
- /Switcher/List/CarProducts/7
Or moving to a dedicated list controller
- /List/CarMakes
- /List/CarProducts/7
- /List/Products
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如何定义路由和整体控制器架构是相当主观的，但我通常会针对此类问题给出相同的建议：
做对你和你的团队有意义的事情。
How you define your routes and overall controller architecture is pretty subjective but I usually give out the same advice for questions like this:
Do what makes sense to you and your team.
路由是一种为数据库驱动的站点请求页面的愚蠢方法。 HTTP 的先驱们正在考虑简单世界中的静态资源。查询字符串更适合数据库应用程序的可靠性和灵活性。查询字符串的唯一缺点是搜索引擎优化，但这是搜索引擎应该解决的问题，而不是世界上所有的网站。
Routes are a silly way to request pages for a database driven site. Pioneers of HTTP were thinking of static resources in a simple world. Query strings are better for database applications for reliability and flexibility. The only downside to query strings is search engine optimization but that is something search engines should fix and not all the web sites in the world.