Repository navigation
api_main
Im Folgenden wird das Rest interface beschrieben.
Es werden alle Ressorucen in einem Event Stream Topic veröffentlicht.
Es werden andere Event Stream Topics gelesen, weitere Informationen dazu befinden sich im Abschnitt Events. Mehrere Notlagen können niemals die gleiche origin-ID haben.
Es können Notlagen angelegt werden, abgefragt werden, sowie als Bestätigt und Gelöst markiert werden.
Eine als Gelöst markierte Notlage kann nicht mehr verändert werden. Im normalen Betreib werden über Events neue Notlagen erzeugt.
| Aktion | Pfad | JSON arg | Rückgabe | HATEOAS | Erklärung |
|---|---|---|---|---|---|
| Post | /Notlage | Nachricht | Ressource | Self-Link | Legt neue Notlage an |
| Put | /Notlage/{id}/bestaetigen | BP | Ressource | Self-Link Lösen-Link | Zustand in Bestätigt ändern |
| Put | /Notlage/{id}/loesen | BP | Ressource | Self-Link | Zustand in Gelöst ändern |
| Get | /Notlage/{id} | Keine | Ressource | Self-Link Aktionen-Links | Spezifische Notlage anfordern |
| Get | /Notlage | Keine | Liste URIs | Alle Notlage anfordern |
Notlage Ressource:
{
"dvp": {
"dvpID": "4d8c9ex1-e739-40ec-b096-3do496a17fh6"
},
"status": "IN_BEARBEITUNG",
"origin": "ungewöhnliche Route",
"idOrigin": "0d8e9ea1-e439-43eb-b096-3db416a77cb2",
"geloest": false,
"bestaetigt": false,
"notlageBestaetigung": {
"bestaetigerBpID": null,
"istBestaetigt": false
},
"notlageLoesung": {
"loeserBpID": null,
"istGeloest": false
},
"extraData": {
"data": "zusatz Info"
},
"offen": true,
"_links": {
"self": {
"href": "http://localhost:8080/notlage/1",
"type": "GET"
},
"bestätigen": {
"href": "http://localhost:8080/notlage/1/bestaetigen",
"type": "PUT"
},
"lösen": {
"href": "http://localhost:8080/notlage/1/loesen",
"type": "PUT"
}
}
}Nachricht Format
{
"dvpID": "4d8c9ex1-e739-40ec-b096-3do496a17fh6",
"origin": "ungewöhnliche Route",
"origin_id":"0d8e9ea1-e439-43eb-b096-3db416a77cb2",
"payload": "extra Daten Ort Datum"
}Es können neue Bezugspersonen angelegt werden, sowie deren Verfügbarkeiten und Kommunikationskanäle bearbeitet werden. Über Events werden im normalen Betrieb die Bezugspersonen angelegt.
| Aktion | Pfad | JSON arg | Rückgabe | HATEOAS | Erklärung |
|---|---|---|---|---|---|
| Post | /Bezugsperson | BP-ID-Nach | Self-Link | Legt neue Bezugsperson an | |
| GET | /Bezugsperson/{id} | Ressource | Self-Link Anwesenheit-Link | Bezugsperson Ressource anfordern | |
| DELETE | /Bezugsperson/{id} | Bezugsperson löschen | |||
| POST | /Bezugsperson/{id}/Anwesenheit | Anwesenheit | Self-Link | Anwesenheit hinzufügen | |
| GET | /Bezugsperson/{id}/Anwesenheit | Liste von URIs | Self-Link | Anwesenheiten anfordern | |
| GET | /Bezugsperson/{id}/Anwesenheit/{id} | Ressource | Self-Link | Anwesenheit anfordern | |
| DELETE | /Bezugsperson/{id}/Anwesenheit/{id} | Anwesenheit löschen |
BP Ressource:
{
"bp":"4d8c9ex1-e739-40ec-b096-3do496a17fh6"
}Anwesenheit Ressource:
{
"von": dd.MM.yyyy HH:mm,
"bis": dd.MM.yyyy HH:mm
}BP-ID-Nach Format
{
"bp_id_ext":"4d8c9ex1-e739-40ec-b096-3do496a17fh6"
}Benachrichtigungen
Sobald eine Bezugsperson infomiert wurde, wird ein Benachrichtigungsobjekt angelegt und verwaltet.
| Aktion | Pfad | JSON arg | Rückgabe | HATEOAS | Erklärung |
|---|---|---|---|---|---|
| POST | /benachrichtigeBPs | BEN-INFO | Self-Link | Prozess anstoßen | |
| PUT | /Benachrichtigung/{id}/gelesen | Self-Link | Als gelesen markieren | ||
| PUT | /Benachrichtigung/{id}/ablehnen | Self-Link | Als abgelehnt markieren | ||
| PUT | /Benachrichtigung/{id}/bestaetigen | Self-Link | Als bestätigt markiert | ||
| GET | /Benachrichtigung/{id} | Ressource | Self-Link Aktions-Links | Get Ressource |
BEN-INFO Format
{
"notlage_uri":"3",
"dvp_id":"4d8c9ex1-e739-40ec-b096-3do496a17fh6",
"nachricht":"Link zu dem Web Interface",
}Besitzt keine Rest Schnittstellen.
Anhand des Zustandsdiagramms wurden folgende APIs für die Microservices identifiziert und konstruiert.
Das Zustandsdiagramm beschreibt die Zustände und Zustandsübergänge die die Objekte in den einzelnen Kontexten annehmen können.

Folgende APIs wurden identifiziert und realisiert. Nach der Umstellung auf Eventing werden aktuell nur noch folgende APIs benötigt:
URI: /Notlage/{id}/Bestaetigen PUT
**Erwartet:**
BP
**Antwort:**
Ressource Notlage
Link /Notlage/{id}/Loesen
Link self
URI: /Notlage/{id}/Loesen PUT
**Erwartet:**
BP
**Antwort:**
Ressource Notlage
Link self
Vollständigkeitshalber existieren weitere APIs, deren Funktionalität durch Event-Streams abgedeckt wird. Für eine höhere Ausfallsicherheit existieren für alle Zustandsübergänge API-Aufrufe, auch wenn alle, bis auf die zwei oben beschriebenen, im Normalfall nicht verwendet werden sollten.

APIs MS-Notlage
URI: /Notlage POST
**Erwartet:**
DVP-ID
Nachricht
**Antwort:**
URI Notlage
URI: /Notlage/{id} GET
**Antwort:**
Notlage
URI Notlage
URI: /Notlage/{id} POST
**Erwartet:**
Notlage
**Antwort:**
URI Notlage
APIs MS-BP
URI: /Benachrichtigung POST
**Erwartet:**
URI Notlage
**Antwort:**
URI: /Bezugsperson POST
**Erwartet:**
BP
zugehörige DVPs
Kontaktdaten
**Antwort:**
URI Bezugsperson
URI: /Bezugsperson/{id} GET
**Antwort:**
BP
URI Bezugsperson
URI: /Bezugsperson/{id} DELETE
**Antwort:**
BP (gelöschte)
-
- REST- Oliver Drotbohm
- REWE digital - Ansgar Brauner
- Containerisierung- Axel Burghof
- Eventing - Sebastian Gauder
- UI - Wolf Schlegel, Niko Hellwig
- Brownfield zu Greenfield - Christian Nockemann
- Resilience - Marion Bruns, Komal Ahluwalias
- UI bei REWE digial - Christian Fröhlingsdorf
- 8 things developers should know about microservices - Wolf Schlegel, Laura Ionescu, Felix Hammerl