Które podejście do skonstruowania API ?

Klient chce zainicjalizować operację. Wysyła request, przy czym na poziomie UI ma poinformować czy chce dany request od razu zrealizować, czy na razie tylko ustawić go na oczekujący do późniejszej realizacji/modyfikacji.

Jak najlepiej ugryźć api? Widzę dwa podejścia:

1. Mamy trzy różne end-pointy w kontrolerze.

• do zapisania przesłanej operacji ze statusem PENDING.
• do zrealizowania przesłanej operacji i następnie zapisania ze statusem SENT
• do zrealizowania zapisanej transakcji ze statusem PENDING po ID i następnie update statusu na SENT

2. Dwa endpointy. Request zawiera flagę isSent

• do zrealizowania jeśli flaga == true + zapis operacji z odpowiednim statusem
• do zrealizowania zapisanej transakcji ze statusem PENDING po ID i następnie update statusu na SENT

Imo lepiej podejście nr 1. Nie lubie ifologii. Czy może macie jakiś inny pomysł? Kontrakt Klient - API - dowolny.

Aż 3 endpointy do w zasadzie jednej operacji której stan zależy od flagi? A dlaczego po prostu nie przesłać informacji o statusie operacji chociażby w query parameter?:]

Pytanie pomocnicze - dlaczego klient nie może wysłać dwóch żądań w przypadku, gdy chce wysłać cośtam od razu?

Tak czy inaczej - IMO czytelniej jest wystawić trzy operacje. Dawanie jakichś flag sterujących w parametrze często jest złym pomysłem.

Raczej nie poslugiwal bym sie stanami w API a zrobil to bardziej w rpc style, czyli np:

/api/operations
/api/operations/{operationId}/execute

lub

/api/operations/execute

oczywiscie operations dostosuj do swojej domeny

https://github.com/allegro/restapi-guideline

nie jest to jakiś wyznacznik, ale możesz sobie przejrzeć

Robie tak. W przypadku realizacji:
-> Pierwszy request -> zapisanie requesta ze statusem PENDING
-> Drugi request -> przesłanie otrzymanego ID i realizacja requesta + UPDATE statusu na SENT

W przypadku samego zapisania:
-> Jeden request -> zapisanie requesta ze statusem PENDING

Czyli łącznie dwa endpointy.