Skip to content

Reply-Channels unzureichend in Destination-API-Spec abgebildet

Hintergrund

In der Destination-Payload kommt das replyChannels-Objekt auf der Wurzelebene vor, aber auch unter services. Die betrifft folgende Fälle:

Request-Payload:

  • POST /destination-api/v1/destinations
  • PUT /destination-api/v1/destinations/destinationId
  • PATCH /destination-api/v1/destinations/destinationId

Response-Payload:

  • POST /destination-api/v1/destinations
  • PUT /destination-api/v1/destinations/destinationId
  • PATCH /destination-api/v1/destinations/destinationId
  • GET /destination-api/v1/destinations
  • GET /destination-api/v1/destinations/destinationId
  • GET /submission-api/v1/destinations/destinationId

Das Auftreten auf Wurzelebene ist "legacy" und in der Submission-API als deprecated markiert (seit mindestens 8 Monaten).

Problem

Das replyChannels-Objekt wurde in der Destination-API oft vergessen.

Request-Payload:

  • POST /destination-api/v1/destinations: Fehlt komplett
  • PUT /destination-api/v1/destinations/destinationId: Existiert an Wurzel, fehlt in services
  • PATCH /destination-api/v1/destinations/destinationId: Fehlt komplett

Response-Payload:

  • POST /destination-api/v1/destinations: Existiert an Wurzel, fehlt in services
  • PUT /destination-api/v1/destinations/destinationId: Existiert an Wurzel, fehlt in services
  • PATCH /destination-api/v1/destinations/destinationId: Existiert an Wurzel, fehlt in services
  • GET /destination-api/v1/destinations: Existiert an Wurzel, fehlt in services
  • GET /destination-api/v1/destinations/destinationId: Existiert an Wurzel, fehlt in services

Es ist nicht klar, welcher Ansatz hier verfolgt werden soll. Einerseits ist nachvollziehbar, dass ein deprecated Feld (an der Wurzel) in der neuen API-Spec nicht vorkommen soll. Andererseits wird dieses Feld in den Responses der Destination-API zurückgegeben und man möchte ja eine exakte Übereinstimmung von Spec und Implementierung erreichen.

Lösung

Das fehlende Objekt in services sollte auf jeden Fall überall nachgebessert werden. Den Wurzel-Eintrag kann man entweder ebenfalls überall in der Spec abbilden. Oder aber man entfernt ihn und müsste dann aber auch die Implementierung anpassen (riskant).