推薦的ServiceStack API結(jié)構(gòu)我正在嘗試找出構(gòu)建API的最佳方法; 我們在標(biāo)準(zhǔn)REST結(jié)構(gòu)中設(shè)置了評論（列表一，列出所有，創(chuàng)建，更新等）。在不完全符合示例的情況下：每個評論可以鏈接到一個或多個其他類型，例如事件，位置或事物。我的想法是網(wǎng)址將是：/ event / reviews /（或相反的例如/ reviews / event /）/ location / reviews / / thing / reviews /然而，我可以看到的問題是每個這樣的“GET”應(yīng)該返回父對象，即一個事件。那么使用ServiceStack，處理這種情況的最佳方法是什么？是為每個數(shù)據(jù)請求創(chuàng)建一個自定義服務(wù)而不是濫用開箱即用的REST設(shè)置還是我錯過了一些更基本的東西？
2 回答
米琪卡哇伊
TA貢獻(xiàn)1998條經(jīng)驗 獲得超6個贊
首先，“最佳”解決方案是一個相當(dāng)主觀的術(shù)語。我通常的目標(biāo)是干燥，可重復(fù)使用，高性能的解決方案，促進(jìn)最小的努力，摩擦和chattiness，而其他人可能會定義“最佳”，它遵循REST的原則。因此，根據(jù)目標(biāo)的不同，您將獲得不同的響應(yīng)。我只能提供如何處理它。
ServiceStack服務(wù)實現(xiàn)從其自定義路由中解耦
需要記住的一件事是，您在ServiceStack中定義和設(shè)計服務(wù)的方式與您公開它們的方式完全脫離，因為您可以在任何自定義路徑下公開您的服務(wù)。ServiceStack鼓勵基于消息的設(shè)計，因此您應(yīng)該為每個操作提供不同的消息。
使用邏輯/分層Url結(jié)構(gòu)
我使用邏輯Url結(jié)構(gòu)，我的目標(biāo)是表示名詞的標(biāo)識符，它是分層結(jié)構(gòu)的，即父路徑對您的資源進(jìn)行分類并為其提供有意義的上下文。因此，在這種情況下，如果您想公開事件和評論，我傾向于使用以下url結(jié)構(gòu)：
/events //all events/events/1 //event #1/events/1/reviews //event #1 reviews
這些資源標(biāo)識符中的每一個都可以應(yīng)用任何HTTP謂詞
履行
對于實現(xiàn)，我通常遵循基于消息的設(shè)計，并基于響應(yīng)類型和調(diào)用上下文對所有相關(guān)操作進(jìn)行分組。為此我會做類似的事情：
[Route("/events", "GET")][Route("/events/category/{Category}", "GET")] //*Optional top-level viewspublic 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")] //*Optionalpublic 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; }}并按照類似的模式進(jìn)行活動評論
[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; }}基于這些消息，實現(xiàn)應(yīng)該是相當(dāng)直接的，這些消息（取決于代碼庫大?。┪覍⒃?個EventsService和EventReviewsService類中組織。我應(yīng)該注意，我自己使用多個服務(wù)請求DTO名稱，以避免與同名的數(shù)據(jù)模型發(fā)生沖突。
雖然我已經(jīng)分開UpdateEvent并CreateEvent在這里，但StoreEvent如果用例允許，我有時會將它們合并為一個冪等操作。
物理項目結(jié)構(gòu)
理想情況下，根級AppHost項目應(yīng)保持輕量級且無實現(xiàn)。雖然對于只有少量服務(wù)的小型項目，可以將所有內(nèi)容都放在一個項目中，并根據(jù)需要簡單地擴展您的架構(gòu)。
對于中型到大型項目，我們建議使用下面的物理結(jié)構(gòu)，為了本示例的目的，我們假設(shè)我們的應(yīng)用程序稱為EventMan。
項目的順序也顯示其依賴關(guān)系，例如頂級EventMan項目引用所有子項目，而最后一個EventMan.ServiceModel項目引用無：
- 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.ServiceModelDTO保存在各自獨立的實現(xiàn)和無依賴dll中，您可以自由地在任何.NET客戶端項目中共享此dll - 您可以將其與任何通用C＃服務(wù)客戶端一起使用以提供結(jié)束沒有任何代碼的端到端類型的API。
更新
此推薦的項目結(jié)構(gòu)現(xiàn)在包含在所有ServiceStackVS的VS.NET模板中。
在簡單的客戶REST示例有創(chuàng)建一個簡單的REST服務(wù)利用RDBMS的小型自包含的，真實的例子。
- 2 回答
- 0 關(guān)注
- 821 瀏覽
添加回答
舉報
0/150
提交
取消