推荐的ServiceStack API结构
我正在尝试制定构建API的最佳方式; 我们有评论，我们已经在标准的REST结构（列表一，列出所有，创建，更新等）中设置。 不太适合的例子是：每个评论可以链接到一个或多个其他类型，例如事件，位置或事物。
我的想法是这些网址应该是：/ event / reviews /（或者这个eg / reviews / event /）的相反位置/ location / reviews / / thing / reviews /
然而，我可以看到的问题是每个这些的“GET”应该返回父对象，即事件。
所以使用ServiceStack，处理这种情况的最佳方法是什么？ 它是为每个数据请求创建一个定制服务，而不是滥用开箱即用的REST设置，或者我错过了更基础的东西？
首先，“最佳”解决方案是一个相当主观的术语。 我通常会瞄准DRY，可重复使用，高性能的解决方案，以促进最少的努力，摩擦和讨厌，而其他人可能会定义“最佳”，它遵循REST的原则。 因此，根据目标是什么，你会得到不同的回应。 我只能提供我将如何接近它。
ServiceStack服务实现与其自定义路由分离
需要记住的一件事是，如何定义和设计ServiceStack中的服务将如何公开，因为您可以在任何自定义路由下公开您的服务。 ServiceStack鼓励基于消息的设计，因此您应该为每个操作提供明确的消息。
使用逻辑/分层Url结构
我会使用一个逻辑Url结构，我的目的是表示一个名词的标识符，这个名词是分层结构化的，也就是说，父路径会对您的资源进行分类并为其提供有意义的上下文。 因此，在这种情况下，如果您想公开事件并评论，我的倾向是使用以下url结构：
/events //all events
/events/1 //event #1
/events/1/reviews //event #1 reviews
这些资源标识符中的每一个都可以应用任何HTTP动词
履行
对于实现，我通常遵循基于消息的设计，并根据响应类型和调用上下文对所有相关操作进行分组。 为此，我会做一些事情：
[Route("/events", "GET")]
[Route("/events/category/{Category}", "GET")] //*Optional top-level views
public class SearchEvents : IReturn<SearchEventsResponse>
{
//Optional resultset filters, e.g. ?Category=Tech&Query=servicestack
public string Category { get; set; }
public string Query { get; set; }
}
[Route("/events", "POST")]
public class CreateEvent : IReturn<Event>
{
public string Name { get; set; }
public DateTime StartDate { get; set; }
}
[Route("/events/{Id}", "GET")]
[Route("/events/code/{EventCode}", "GET")] //*Optional
public class GetEvent : IReturn<Event>
{
public int Id { get; set; }
public string EventCode { get; set; } //Alternative way to fetch an Event
}
[Route("/events/{Id}", "PUT")]
public class UpdateEvent : IReturn<Event>
{
public int Id { get; set; }
public string Name { get; set; }
public DateTime StartDate { get; set; }
}
并按照类似的模式进行活动评论
[Route("/events/{EventId}/reviews", "GET")]
public class GetEventReviews : IReturn<GetEventReviewsResponse>
{
public int EventId { get; set; }
}
[Route("/events/{EventId}/reviews/{Id}", "GET")]
public class GetEventReview : IReturn<EventReview>
{
public int EventId { get; set; }
public int Id { get; set; }
}
[Route("/events/{EventId}/reviews", "POST")]
public class CreateEventReview : IReturn<EventReview>
{
public int EventId { get; set; }
public string Comments { get; set; }
}
基于这些消息，实现应该相当直接，根据这些消息（取决于代码库的大小），我将在2个EventsService和EventReviewsService类中进行组织。 我应该注意到，我使用服务请求DTO名称的多元化来避免与同名数据模型冲突。
虽然我在这里分开了UpdateEvent和CreateEvent ，但如果用例允许，我有时会将它们合并为一个幂等StoreEvent操作。
物理项目结构
理想情况下，根级AppHost项目应该保持轻量级且免执行。 尽管对于只有少量服务的小型项目来说，所有事情都可以在单个项目中进行，并根据需要简单地增加架构。
对于大中型项目，我们推荐下面的物理结构，就本示例而言，我们假设我们的应用程序称为EventMan 。
项目的顺序也显示其依赖关系，例如顶级EventMan项目引用所有子项目，而最后一个EventMan.ServiceModel项目引用none ：
- EventMan
AppHost.cs // ServiceStack ASP.NET Web or Console Host Project
- EventMan.ServiceInterface // Service implementations (akin to MVC Controllers)
EventsService.cs
EventsReviewsService.cs
- EventMan.Logic //For larger projs: pure C# logic, data models, etc
IGoogleCalendarGateway //E.g of a external dependency this project could use
- EventMan.ServiceModel //Service Request/Response DTOs and DTO types
Events.cs //SearchEvents, CreateEvent, GetEvent DTOs
EventReviews.cs //GetEventReviews, CreateEventReview
Types/
Event.cs //Event type
EventReview.cs //EventReview type
通过将EventMan.ServiceModel DTO保存在各自独立的实现和无依赖关系的dll中，您可以自由地在任何.NET客户端项目中共享此dll - 您可以与任何通用C＃服务客户端一起使用提供没有任何代码的端到端类型化API。
更新
此推荐的项目结构现在包含在所有ServiceStackVS的VS.NET模板中。
简单客户REST示例有一个使用RDBMS创建简单REST服务的小型自包含实例。
不知道它是否有助于您的场景/理解，但我觉得这个演示文稿很有用：
设计一个漂亮的REST + JSON API
链接地址: http://www.djcxy.com/p/20515.html