Jak obsługiwać polecenia w REST podczas wspólnego korzystania z usług REST, CQRS i EventSourcing?

Question

Rozważmy następujące gruboziarnistej API REST dla zasobu Kontakt

POST   /api/contacts        
GET   /api/contacts        
GET   /api/contacts/:id       
PUT   /api/contacts/:id       
DELETE  /api/contacts/:id       

Rozważ użycie eventsourcing dla zasobu kontaktowej, czyli rozkazy są sprawdzane i zdarzenia są przechowywane. Zatem każde zdarzenie musi być przechowywane, w tym każda zmiana poziomu pola.

CreateContactCommand -> | Contact("john", "doe", 25) | -> ContactCreatedEvent 
FirstNameChangeCommand -> | Contact("jane", "doe", 25) | -> FirstNameChangedEvent 
LastNameChangeCommand -> | Contact("jane", "dear", 25) | -> LastNameChangedEvent 
AgeChangeCommand -> | Contact("jane", "doe", 30) | -> AgeChangedEvent 

Teraz, łącząc REST i EventSourcing oba.

Wykonywanie REST, w jaki sposób klient komunikuje się z powyższymi standardowymi interfejsami API usług REST w celu zmiany na poziomie pola, aby wygenerować polecenia po punkcie końcowym REST po stronie serwera?

Najważniejsze pytanie brzmi: jak zaprojektować interfejs REST API, aby mógł on obsługiwać polecenia, które ostatecznie wspierają eventourcing?

Jeśli ktokolwiek mógłby rzucić światło na to, pomoc byłaby bardzo ceniona.

Answer 1

CQRS i Sourcing zdarzeń nie jest ani zasadą projektowania interfejsu API, ani nie jest architekturą najwyższego poziomu. Jeśli jednak chcesz "udostępnić" swój interfejs API jako oparty na zadaniach interfejs API API, możesz odsłonić łącza jako część kontaktu zasób.

GET /contacts/1234 

Response

200 OK 
<contact> 
    <atom:link href="/contacts/1234/first-name" rel="first-name" /> 
    <atom:link href="/contacts/1234/last-name" rel="last-name" /> 
    <atom:link href="/contacts/1234/age" rel="age" /> 
    <first-name>Jane</first-name> 
    <last-name>Doe</last-name> 
    <age>25</age> 
</contact> 

Zakłada się tutaj, że zmienisz API do prawdalevel 3 REST API.

Również /contacts/1234 zaakceptuje tylko GET i DELETE (niePUT) wnioski. Jeśli klient chce zmienić np. pierwsza nazwa kontaktu, musi śledzić link z typem związku first-name i zrobić PUT żądania wobec tego zasobu:

PUT /contacts/1234/first-name 
<first-name>John</first-name> 

nic innego niż first-name dziedzinie PUT tutaj powinny być pominięte lub odrzucone.

Tak więc, gdy usługa otrzymuje PUT przeciwko pierwszej nazwie, jest to polecenie zmiany imienia kontaktu.

To jeszcze nie jest właściwa zadanie oparte API ponieważ nie uchwycić dlaczego pierwsze zmiany nazwy, ale mam nadzieję, że masz pomysł.

Answer 2

REST to rozproszony aplikacyjny styl architektoniczny dla sieci. Sieć ma własne reguły i ograniczenia, jest to obszar reprezentacji i zasobów, a nie zadań, poleceń i zapytań.

Sieć jest niższa niż Twoja aplikacja. Projektując swoje zasoby HTTP, musisz pomyśleć o buforowaniu, wersjonowaniu, powtarzalności, wydajności, luźnym sprzężeniu w kontekście sieciowym, więc możesz nie chcieć, aby były dokładnie dopasowane do jednostek domen, , nie mówiąc już o właściwościach tych podmiotów.Ponadto protokół HTTP ma bardzo ograniczoną liczbę czasowników, a gdy komendy zawodzą, zasoby niekoniecznie są najlepszym wyborem do opisania zadania lub działania.

Dlatego ścisła relacja jeden-do-jednego między poleceniami, które mają sens w Twojej domenie i para (zasobów, czasowników), nie zawsze jest pożądana lub odpowiednia. Możesz chcieć pójść dalej i zaprojektować własny protokół aplikacji dla klientów REST, aby rozmawiać z serwerem zgodnie z zasadami. DAP jest odzwierciedlone w hiper-linkowych powiązaniach i relacjach dla przejść, jak zauważył Mark, ale można również użyć niestandardowych typów treści, aby lepiej opisać rodzaj ładunku w żądaniach lub odpowiedziach. Mogą na przykład zawierać typ wysyłanego polecenia domeny.

Jeśli spojrzysz na this article, zobaczysz, że para (POST, api/inventoryItem/{id}) nie jest unikalna na wykresie w "Zasobach". Może być używany do transportu RemoveItemsFromInventoryCommand lub CheckInItemsToInventoryCommand. Sposób określenia, że ​​na poziomie żądania HTTP używa się niestandardowego nagłówka typu treści: Content-Type:application/json;domain-model=RemoveItemsFromInventoryCommand lub Content-Type:application/json;domain-model=CheckInItemsToInventoryCommand.