Pełen REST czy messages via POST - event sourcing

Robię sobie dla sportu collaborative todo app z wykorzystaniem Reduksa i event sourcingu. Apka działa tak, że każda akcja modyfikująca state jest odpalana jako akcja reduksowa (dodatkowo jest zrobiony middleware reduksowy, który zrzuca wszystkie akcje do event loga). Zastanawiam się czy stosować RESTa czy go olać i wysyłać wszystko POSTem jako gotowe message. Docelowo apka będzie pewnie na Socket.io, no ale aktualnie rozważam przypadek z "klasycznym" backendem. Konkrety:

• mam na backendzie podefiniowane akcje w stylu:

export const ADD_TODO = 'ADD_TODO'
export const REMOVE_TODO = 'REMOVE_TODO'
export const DELETE_TODO = 'DELETE_TODO'

// i dalej action creatory w stylu:
export const addTodo = (title, description) => ({
  type: ADD_TODO,
  payload: {
    id: uuid(),
    title,
    description
  }
})

export const removeTodo = (id) => ({
  type: REMOVE_TODO,
  payload: {
    id
  }
})

• pominę reducery bo sa nieistotne dla przykładu, routing teraz wygląda mniej więcej tak (orginalna apka jest w Koa, ale pokazuję Expressa bo więcej osób go zna):

router
  .get('/todos', (req, res) => {
    res.send(store.getState().todos)
  })
  .post('/todos', (req, res) => {
    store.dispatch(addTodo(req.body.title, req.body.description))
    res.statusStatus(201)
  })
  .delete('/todos/:id', (req, res) => {
    store.dispatch(removeTodo(req.params.id))
    res.sendStatus(200)
  })

Alternatywnie mógłbym praktycznie pozbyć się action creatorów z backendu i wysyłać POSTem gotowe akcje na backend, wtedy routing ograniczyłby się do POSTa i GETa, coś w stylu:

router
  .get('/todos', (req, res) => {
    res.send(store.getState().todos)
  })
  .post('/', (req, res) => {
    store.dispatch(req.body) // body zawiera gotową akcję
    res.sendStatus(200)
  })

Pomijam powyżej obsługę błedów itp

Które podejście wydaje się Wam lepsze? Pełen REST czy GETy dla kolekcji i pojedynczy POST rozpakowujący przesłaną z frontendu akcję? Może jeszcze coś innego?

https://en.wikipedia.org/wiki/Representational_state_transfer

POST - Create a new entry in the collection. The new entry's URI is assigned automatically and is usually returned by the operation

2 przypadek nie jest ok, jeżeli chodzi również o założenia z "Architectural properties":

1. Performance
2. Scalability

W kolekcji może być wiele elementów, przy małej aplikacji TODO to przejdzie. Przy paru milionach rekordach w kolekcji może być problem.

@Krzysztof Bogdan:
To, że nie jest to zgodne z REST to wiem, tego dotyczy pytanie ;) Taki GraphQL też nie jest zgodny z REST i nie musi być.

Mógłbyś rozwinąć kwestię performance i scalability?

Trochę źle zrozumiałem, myślałem że chcesz wysyłać wszystkie elementy kolekcji jako POST żeby serwer sobie zaktualizował stan po swojej stronie.
W związku z tym można wykreślić problemy z performance i scalability.

Jeżeli rozumiem body.action ma w sobie 2 informacje: 1. co zrobić; 2. dane; czyli takie coś ala JSON-RPC.

Nie ważne czy się zrobi to RESTowo czy RPC, postarałbym się nie mixować tych sposobów czyli

• albo tego get`a też zrobił jako RPC
• albo zrezygnował z RPC

Jakbym tworzył API dla kogoś to trzymałbym się jak podejścia REST`owego, dużo osób wie o co chodzi i jest dobry tooling

Tak, dobrze rozumiesz - req.body zawierałoby standardową reduksową akcję typu:

{
  "type": "ADD_TODO",
  "payload": {
    "title": "Some todo",
    "description": "Some description..."
  }
}

Słuszna uwaga na temat jednolitego API - pobieranie przez GET /collection zastosowałem ze względu na wygodę - nie chcę pobierania danych rejestrować w event logu bo nie zmienia to stanu aplikacji i w przy obecnej implementacji podczas restore aplikacji niepotrzebnie się te akcje wykonają.
Z drugiej strony informacja o tym kto i jak często pobiera jakieś dane może być bardzo cenna - a w sumie o to chodzi by nie tracić żadnych danych. Wymaga to przeróbki restora, ale ma sens (no i api jest jenolite przy okazji tak jak sugerujesz).
Dzięki!

W kwestii RESTa - to mniej tyle wiem co ateista rozwikłujący zagadnienie pochodzenia ducha świętego.

Ale jeśli bawisz się ES - to opcja z wysyłaniem całej akcji wychodzi mi naturalnie - dokładnie tak czasem robię - wpakowujesz od razu akcję jako event - piękny skrót.
Szczególnie dobrze działa wtedy kiedy masz współdzielony kod na serwerze i kliencie (np,. reducery możesz mieć dokładnie te same).
Jeszcze gorzej, potem te same akcje można wysyłać socketem innym klientom :-), i w ten sposób w zasadzie nie potrzebujemy RESTowego GETa Można wykorzystać niby do stanu początkowego ... ale czemu by miał serwer tego nie wysłać jako serię akcji?... (na pewno jest to mniej wydajne, za to przynajmniej zabawne...).

@jarekr000000:
No myślę, że do czegoś takiego właśnie zmierzam ;)