권장 ServiceStack API 구조

권장 ServiceStack API 구조

---

API를 구성하는 가장 좋은 방법을 찾고 있습니다. 표준 REST 구조 (목록 하나, 모두 나열, 생성, 업데이트 등)에서 설정 한 리뷰가 있습니다. 예에 맞지 않는 경우 : 각 리뷰는 이벤트, 위치 또는 사물과 같은 하나 이상의 다른 유형에 연결될 수 있습니다.

내 생각은 URL이 / event / reviews / (또는 이것의 반대 예 : / 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; }
}

The implementation should be fairly straight forward based on these messages, which (depending on code-base size) I would organize in 2 EventsService and EventReviewsService classes. I should note that I use pluralization for Service Request DTO names myself to avoid clashing with data models of the same name.

Although I've separated UpdateEvent and CreateEvent here, I will sometimes will merge them into a single idempotent StoreEvent operation if the use-case permits.

Physical Project Structure

Ideally the root-level AppHost project should be kept lightweight and implementation-free. Although for small projects with only a few services it's ok for everything to be in a single project and to simply grow your architecture when and as needed.

For medium-to-large projects we recommend the physical structure below which for the purposes of this example we'll assume our Application is called EventMan.

The order of the projects also show its dependencies, e.g. the top-level EventMan project references all sub projects whilst the last EventMan.ServiceModel project references 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

With the EventMan.ServiceModel DTO's kept in their own separate implementation and dependency-free dll, you're freely able to share this dll in any .NET client project as-is - which you can use with any of the generic C# Service Clients to provide an end-to-end typed API without any code-gen.

---

Update

• This recommended project structure is now contained in all ServiceStackVS' VS.NET Templates.

• The Simple Customer REST Example has a small self-contained, real-world example of creating a simple REST Service utilizing an RDBMS.

---

Not sure if it will help in your scenario/understanding, but I find this presentation helpful:

Designing a Beautiful REST+JSON API

참고URL : https://stackoverflow.com/questions/15231537/recommended-servicestack-api-structure