In meinem Projekt mit DDD-Methodik.

Das Projekt hat das Aggregat (Entität) Deal. Dieses Aggregat hat viele Anwendungsfälle.

Für dieses Aggregat muss ich eine Rest-API erstellen.

Mit Standard: Erstellen und Löschen kein Problem.

1) CreateDealUseCase (Name, Preis und viele andere Parameter);

POST /rest/{version}/deals/
{ 
   'name': 'deal123',
   'price': 1234;
   'etc': 'etc'
}

2) DeleteDealUseCase(Ich würde

DELETE /rest/{version}/deals/{id}

Aber was soll ich mit den restlichen Anwendungsfällen machen?

HoldDealUseCase (id, reason);UnholdDealUseCase (id);CompleteDealUseCase (id und viele andere Parameter);CancelDealUseCase (id, amercement, reason);ChangePriceUseCase (id, newPrice, reason);ChangeCompletionDateUseCase (id, newDate, amercement, whyChanged);etc (insgesamt 20 Anwendungsfälle) ...

Was sind die Lösungen?

1)Verben verwenden:

PUT /rest/{version}/deals/{id}/hold
{ 
   'reason': 'test'
}

Aber! Verben können nicht in der URL verwendet werden (in der REST-Theorie).

2)Verwende den abgeschlossenen Zustand (das wird nach dem Anwendungsfall sein):

PUT /rest/{version}/deals/{id}/holded
{ 
   'reason': 'test'
}

Persönlich sieht es für mich hässlich aus. Vielleicht bin ich falsch

3)Verwenden Sie 1 PUT-Anforderung für alle Operationen:

PUT /rest/{version}/deals/{id}
{ 
   'action': 'HoldDeal',
   'params': {'reason': 'test'}
}

PUT /rest/{version}/deals/{id}
{ 
   'action': 'UnholdDeal',
   'params': {}
}

s ist schwierig, im Backend damit umzugehen. Darüber hinaus ist es schwierig zu dokumentieren. Da 1 Aktion hat viele verschiedene Varianten von Anfragen, von denen bereits bestimmte Antworten abhängen.

Alle Lösungen haben erhebliche Nachteile.

Ich habe viele Artikel über den REST im Internet gelesen. Überall nur eine Theorie, wie man hier mit meinem spezifischen Problem umgehen kann?