streams - Übungen - Microservices - Schritt 03
--
Validierung in take-order-service entfernt

* Validierung der übergebenen Zahlen entfernt
* Dies soll ja jetzt iin einem separatem Microservice umgesetzt werden

streams - Übungen - Microservices - Schritt 02
--
Release für details:02

streams - Übungen - Microservices - Schritt 02
--
Referenz auf State-Store wird dauerhaft gespeichert

* Die Referenz auf den State-Store wird nicht bei jedem GET-Aufruf neu geholt
* Der richtige Ort dafür ist ein State-Listener
* Grund: Ruft man die Refrenz direkt nach dem Start der KafkaStreams-Instanz
  auf, befindet sich die App noch nicht im Zustand RUNNING und der Abruf
  schlegt fehl!

streams - Übungen - Microservices - Schritt 02
--
Details-Service für Order-Aufträge implementiert

* Der Service lauscht auf dem "orders"-Topic und baut den Zustand auf
* Über eine REST-Anfrage kann der aktuelle Zustand erfragt werden

streams - Übungen - Microservices - Schritt 01
--
Release für take-order:01

streams - Übungen - Microservices - Schritt 01
--
README.sh wartet auf /actuator/health, anstatt eine fixe Zeit (REDONE)

(Version aus ursprünglicher Übung übernommen)

streams - Übungen - Microservices - Schritt 01
--
Dockerfile mit ENTRYPOINT und CMD

streams - Übungen - Microservices - Schritt 01
--
README.sh wartet auf /actuator/health, anstatt eine fixe Zeit

streams - Übungen - Microservices - Schritt 01
--
Beispiele für Order-Requests hinhzugefügt

(Der Accept-Header ist sinnvoll, weil sich verschiedene Versionen von
httpie-Versionen sonst nicht einheitlich verhalten)

streams - Übungen - Microservices - Schritt 01
--
Microservice Take-Order implementiert

* Microservice implementiert, der neue Orders annimmt
* Orders werden asynchron angenommen
* HTTP-Antwort erfolgt erst, wenn Order erfolgreich in Topic geschrieben
* Für jede Anfrage wird eine UUID generiert, die als Schlüssel fungiert
* Bei Erfolg wird eine URI zurückgegeben, unter der die Order abfragbar ist