[Wegrzynski]

#programowanie Mirki, jak powinno być zaprojektowane REST API gdy jest wykorzystywane do komunikacji pomiędzy serwisami w ramach jednego systemu -> nie jest wystawiane na świat? Chodzi mi o to jak dużo powinno być end-pointów i jak bardzo zahardkodowane powinny być?

1. Jak mamy obiekt którego poszczególne pola mogą być zmienione (UPDATE) przez różne inne serwisy, to ile powinno być end-pointów, jeden do aktualizowania czy wiele - dla każdego osobnego pola lub ich grupy osobno?

W pierwszym przypadku wszystkie serwisy muszą w body zawierać pełne zapytanie które trafi do bazy danych - identyfikator, które pole/-a chcemy zmienić oraz na jaką wartość, a w drugim będzie ich więcej, ale będą musiały zawierać tylko identyfikator obiektu oraz nową wartość pola, na którego end-point wysłaliśmy requesta.

2. Powinny być osobno end-pointy do zmiany jednego oraz wielu obiektów czy wystarczy jeden?

Jak mamy end-point którym możemy zmienić jeden lub wiele obiektów, to czy jest sens robić osobnego end-pointa na zmianę tylko i wyłączenie jednego obiektu?

Piszę wszędzie o obiektach, bo używam MongoDB.

Pytam o dobre praktyki ( ͡° ͜ʖ ͡°) Jak ktoś zamierza napisać "to zależy", to proszę o nakreślenie od czego zależy ( ͡° ᴥ ͡°)

[k.....e]

@Wegrzynski:
1. jeden, PATCH lub PUT zależnie od tego jak chcesz robić update
2. osobno np /api/customers i /api/customers/123456

https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/

[E.....o]

@Wegrzynski: to są osobne rzeczy całkowicie, w rest api definiujesz sobie zasoby i na nich operujesz, a to czy implementacja twojego serwisu dla danego zasobu operuje na jednym obiekcie czy na kilku to inna sprawa. Wiec musisz sam sobie odpowiedziec jak to api sensownie zdefiniowac dla twojego usecasu