推荐的ServiceStack API结构

Question

推荐的ServiceStack API结构

我正在尝试找出构建API的最佳方法; 我们在标准REST结构中设置了评论（列表一，列出所有，创建，更新等）。在不完全符合示例的情况下：每个评论可以链接到一个或多个其他类型，例如事件，位置或事物。

我的想法是网址将是：/ event / reviews /（或相反的例如/ reviews / event /）/ location / reviews / / thing / reviews /

然而，我可以看到的问题是每个这样的“GET”应该返回父对象，即一个事件。

那么使用ServiceStack，处理这种情况的最佳方法是什么？是为每个数据请求创建一个自定义服务而不是滥用开箱即用的REST设置还是我错过了一些更基本的东西？

Answer 1

首先，“最佳”解决方案是一个相当主观的术语。我通常的目标是干燥，可重复使用，高性能的解决方案，促进最小的努力，摩擦和chattiness，而其他人可能会定义“最佳”，它遵循REST的原则。因此，根据目标的不同，您将获得不同的响应。我只能提供如何处理它。ServiceStack服务实现从其自定义路由中解耦需要记住的一件事是，您在ServiceStack中定义和设计服务的方式与您公开它们的方式完全脱离，因为您可以在任何自定义路径下公开您的服务。ServiceStack鼓励基于消息的设计，因此您应该为每个操作提供不同的消息。使用逻辑/分层Url结构我使用逻辑Url结构，我的目标是表示名词的标识符，它是分层结构的，即父路径对您的资源进行分类并为其提供有意义的上下文。因此，在这种情况下，如果您想公开事件和评论，我倾向于使用以下url结构：/events&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//all&nbsp;events/events/1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//event&nbsp;#1/events/1/reviews&nbsp;&nbsp;&nbsp;//event&nbsp;#1&nbsp;reviews这些资源标识符中的每一个都可以应用任何HTTP谓词履行对于实现，我通常遵循基于消息的设计，并基于响应类型和调用上下文对所有相关操作进行分组。为此我会做类似的事情：[Route("/events",&nbsp;"GET")][Route("/events/category/{Category}",&nbsp;"GET")]&nbsp;//*Optional&nbsp;top-level&nbsp;viewspublic&nbsp;class&nbsp;SearchEvents&nbsp;:&nbsp;IReturn<SearchEventsResponse>{ &nbsp;&nbsp;&nbsp;//Optional&nbsp;resultset&nbsp;filters,&nbsp;e.g.&nbsp;?Category=Tech&Query=servicestack &nbsp;&nbsp;&nbsp;public&nbsp;string&nbsp;Category&nbsp;{&nbsp;get;&nbsp;set;&nbsp;}&nbsp; &nbsp;&nbsp;&nbsp;public&nbsp;string&nbsp;Query&nbsp;{&nbsp;get;&nbsp;set;&nbsp;}}[Route("/events",&nbsp;"POST")]public&nbsp;class&nbsp;CreateEvent&nbsp;:&nbsp;IReturn<Event>{ &nbsp;&nbsp;&nbsp;public&nbsp;string&nbsp;Name&nbsp;{&nbsp;get;&nbsp;set;&nbsp;} &nbsp;&nbsp;&nbsp;public&nbsp;DateTime&nbsp;StartDate&nbsp;{&nbsp;get;&nbsp;set;&nbsp;}}[Route("/events/{Id}",&nbsp;"GET")][Route("/events/code/{EventCode}",&nbsp;"GET")]&nbsp;//*Optionalpublic&nbsp;class&nbsp;GetEvent&nbsp;:&nbsp;IReturn<Event>{ &nbsp;&nbsp;&nbsp;public&nbsp;int&nbsp;Id&nbsp;{&nbsp;get;&nbsp;set;&nbsp;} &nbsp;&nbsp;&nbsp;public&nbsp;string&nbsp;EventCode&nbsp;{&nbsp;get;&nbsp;set;&nbsp;}&nbsp;//Alternative&nbsp;way&nbsp;to&nbsp;fetch&nbsp;an&nbsp;Event}[Route("/events/{Id}",&nbsp;"PUT")]public&nbsp;class&nbsp;UpdateEvent&nbsp;:&nbsp;IReturn<Event>{ &nbsp;&nbsp;&nbsp;public&nbsp;int&nbsp;Id&nbsp;{&nbsp;get;&nbsp;set;&nbsp;} &nbsp;&nbsp;&nbsp;public&nbsp;string&nbsp;Name&nbsp;{&nbsp;get;&nbsp;set;&nbsp;} &nbsp;&nbsp;&nbsp;public&nbsp;DateTime&nbsp;StartDate&nbsp;{&nbsp;get;&nbsp;set;&nbsp;}}并按照类似的模式进行活动评论[Route("/events/{EventId}/reviews",&nbsp;"GET")]public&nbsp;class&nbsp;GetEventReviews&nbsp;:&nbsp;IReturn<GetEventReviewsResponse>{ &nbsp;&nbsp;&nbsp;public&nbsp;int&nbsp;EventId&nbsp;{&nbsp;get;&nbsp;set;&nbsp;}}[Route("/events/{EventId}/reviews/{Id}",&nbsp;"GET")]public&nbsp;class&nbsp;GetEventReview&nbsp;:&nbsp;IReturn<EventReview>{ &nbsp;&nbsp;&nbsp;public&nbsp;int&nbsp;EventId&nbsp;{&nbsp;get;&nbsp;set;&nbsp;} &nbsp;&nbsp;&nbsp;public&nbsp;int&nbsp;Id&nbsp;{&nbsp;get;&nbsp;set;&nbsp;}}[Route("/events/{EventId}/reviews",&nbsp;"POST")]public&nbsp;class&nbsp;CreateEventReview&nbsp;:&nbsp;IReturn<EventReview>{ &nbsp;&nbsp;&nbsp;public&nbsp;int&nbsp;EventId&nbsp;{&nbsp;get;&nbsp;set;&nbsp;} &nbsp;&nbsp;&nbsp;public&nbsp;string&nbsp;Comments&nbsp;{&nbsp;get;&nbsp;set;&nbsp;}}基于这些消息，实现应该是相当直接的，这些消息（取决于代码库大小）我将在2个EventsService和EventReviewsService类中组织。我应该注意，我自己使用多个服务请求DTO名称，以避免与同名的数据模型发生冲突。虽然我已经分开UpdateEvent并CreateEvent在这里，但StoreEvent如果用例允许，我有时会将它们合并为一个幂等操作。物理项目结构理想情况下，根级AppHost项目应保持轻量级且无实现。虽然对于只有少量服务的小型项目，可以将所有内容都放在一个项目中，并根据需要简单地扩展您的架构。对于中型到大型项目，我们建议使用下面的物理结构，为了本示例的目的，我们假设我们的应用程序称为EventMan。项目的顺序也显示其依赖关系，例如顶级EventMan项目引用所有子项目，而最后一个EventMan.ServiceModel项目引用无：-&nbsp;EventMan &nbsp;&nbsp;&nbsp;&nbsp;AppHost.cs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;ServiceStack&nbsp;ASP.NET&nbsp;Web&nbsp;or&nbsp;Console&nbsp;Host&nbsp;Project-&nbsp;EventMan.ServiceInterface&nbsp;//&nbsp;Service&nbsp;implementations&nbsp;(akin&nbsp;to&nbsp;MVC&nbsp;Controllers) &nbsp;&nbsp;&nbsp;&nbsp;EventsService.cs&nbsp;&nbsp;&nbsp;&nbsp;EventsReviewsService.cs-&nbsp;EventMan.Logic&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//For&nbsp;larger&nbsp;projs:&nbsp;pure&nbsp;C#&nbsp;logic,&nbsp;data&nbsp;models,&nbsp;etc &nbsp;&nbsp;&nbsp;&nbsp;IGoogleCalendarGateway&nbsp;&nbsp;//E.g&nbsp;of&nbsp;a&nbsp;external&nbsp;dependency&nbsp;this&nbsp;project&nbsp;could&nbsp;use-&nbsp;EventMan.ServiceModel&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//Service&nbsp;Request/Response&nbsp;DTOs&nbsp;and&nbsp;DTO&nbsp;types &nbsp;&nbsp;&nbsp;&nbsp;Events.cs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//SearchEvents,&nbsp;CreateEvent,&nbsp;GetEvent&nbsp;DTOs&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;EventReviews.cs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//GetEventReviews,&nbsp;CreateEventReview &nbsp;&nbsp;&nbsp;&nbsp;Types/ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Event.cs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//Event&nbsp;type &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EventReview.cs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//EventReview&nbsp;type通过将EventMan.ServiceModelDTO保存在各自独立的实现和无依赖dll中，您可以自由地在任何.NET客户端项目中共享此dll - 您可以将其与任何通用C＃服务客户端一起使用以提供结束没有任何代码的端到端类型的API。更新此推荐的项目结构现在包含在所有ServiceStackVS的VS.NET模板中。在简单的客户REST示例有创建一个简单的REST服务利用RDBMS的小型自包含的，真实的例子。