Entwickler

GET/v3/lnp/project/{uniqueid}/document/{documentId}

Anhang eines Rufnummernportierungsprojekts herunterladen

Laden Sie die Dokumentbytes eines Projekts Ihres Kontos herunter und prüfen Sie die Kompatibilität mit dem älteren Speicherformat.

Auf dieser Seite
  1. Konto- und Dokumentzugriff
  2. Dokument bestimmen
  3. Antwort anfordern und speichern
  4. Binäre Antwort und Header
  5. Heruntergeladene Datei prüfen
  6. Kompatibilität mit dem älteren Speicherformat
  7. Fehler und Auswirkungen

Konto- und Dokumentzugriff

Laden Sie einen vorhandenen Anhang aus einem Rufnummernportierungsprojekt herunter, das Ihrem API-Konto gehört. Verwenden Sie ein aktiviertes API-Konto über HTTPS von einer zugelassenen IP-Adresse aus. Das Projekt darf nicht gelöscht sein. Eine Dokument-ID wird innerhalb dieses Projekts gesucht; sie ist kein globaler öffentlicher Download-Link.

Dokument bestimmen

Lesen Sie die Antwort mit den Projektdetails und verwenden Sie einen Eintrag aus der Liste uploads. Der Eintrag enthält die numerische Kennung id, den ursprünglichen Dateinamen, die gespeicherte Dateierweiterung und die relative Adresse download_url. Verwenden Sie die Projektkennung uniqueid und diese Upload-ID, nicht die numerische ID des Projektdatensatzes oder die ID eines Rufnummerndatensatzes.

Lösen Sie eine zurückgegebene relative URL ausschließlich anhand Ihres konfigurierten, vertrauenswürdigen API-Hosts auf. Für den Download ist dieselbe Kontoauthentifizierung erforderlich; Dokumentmetadaten gewähren keinen Zugriff ohne Authentifizierung.

Antwort anfordern und speichern

Setzen Sie PROJECT_ID und DOCUMENT_ID auf Werte aus dem Projekt Ihres Kontos. Kodieren Sie die Projekt-ID für die Verwendung in einer URL. Dieses Beispiel speichert Bytes und Antwortheader getrennt und verwendet einen festgelegten lokalen Ausgabedateinamen, statt dem Dateinamen des Anhangs zu vertrauen.

curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
  --dump-header document-headers.txt \
  --output porting-document.bin \
  "https://api.multitel.net/v3/lnp/project/$PROJECT_ID/document/$DOCUMENT_ID"

Die Anfrage verwendet GET ohne Anfragerumpf. Sie liest einen einzelnen vollständigen Anhang, ohne endpunktspezifische Seitennavigation, JSON-Hülle oder dokumentierte Zusicherung zum Herunterladen von Teilbereichen.

Binäre Antwort und Header

Bei Erfolg enthält der Antwortrumpf die gespeicherten Bytes des Anhangs nach dem Dekodierungsschritt für das ältere Speicherformat, weder base64 noch ein JSON-Antwortobjekt. Die Methode sendet einen Content-Disposition-Header für einen Anhang mit dem gespeicherten Dateinamen, aus dem doppelte Anführungszeichen entfernt wurden. Der Header stellt weder eine garantiert standardkonforme Kodierung noch einen sicheren lokalen Dateipfad bereit; wählen Sie selbst einen Zieldateinamen.

MIME-Typen der Antwort nach Dateierweiterung
Gespeicherte DateierweiterungContent-Type
pdfapplication/pdf
pngimage/png
jpg, jpegimage/jpeg
docapplication/msword
Andere Werteapplication/octet-stream

Beim Abgleich der Dateierweiterung wird nicht zwischen Groß- und Kleinschreibung unterschieden. Die Auswahl des MIME-Typs beruht auf der gespeicherten Dateierweiterung, nicht auf einer Inhaltsprüfung, und garantiert nicht, dass das Dokument gültig ist.

Heruntergeladene Datei prüfen

  1. Prüfen Sie sowohl den HTTP-Status als auch die Antwortheader. Bei Authentifizierungs- oder Suchfehlern kann statt einer Datei eine Antwort im Format JSON von der API zurückgegeben werden. Betrachten Sie nicht jeden nicht leeren Antwortrumpf oder jede gespeicherte Ausgabedatei als erfolgreichen PDF-Download.
  2. Wenn der Antwortrumpf eine Fehlermeldung im Format JSON enthält, prüfen Sie status.code und status.msg. Bewahren Sie Fehlerausgaben getrennt vom erwarteten Dokument auf.
  3. Prüfen Sie, dass die erhaltene Datei nicht leer ist und sich als der erwartete Dateityp öffnen lässt. Wenn Ihnen das Original vorliegt, vergleichen Sie dessen Prüfsumme mit der der Kopie, bevor Sie sich auf die Kopie verlassen.
  4. Wenn das Ergebnis leer oder ungültig ist oder vom Original abweicht, brechen Sie ab und bitten Sie den Support, den gespeicherten Anhang zu prüfen. Wiederholte Downloads beheben keine Speicherfehler.

Kompatibilität mit dem älteren Speicherformat

Der aktuelle Upload-Pfad der API und die geprüften Upload-Schreibkomponenten des Portals und des Altsystems speichern Dokumentbytes mit Escape-Sequenzen. Dieser Download macht diese Maskierung rückgängig. Offline-Tests der tatsächlichen Verarbeitungsfunktion erhalten bei diesem Speicherformat alle Bytewerte und wörtlichen Rückwärtsschrägstriche.

Dies ist keine Zusicherung für jeden historischen oder extern importierten Datensatz. Die Verarbeitungsfunktion dekodiert den gespeicherten Binärdatenblock immer und erkennt nicht, ob ein Datensatz ohne die erwartete Maskierung importiert wurde. Sie greift auch nicht ersatzweise auf einen Dateipfad zurück, wenn ein Datensatz keinen gespeicherten Binärdatenblock enthält. Solche Datensätze können veränderte Bytes oder eine leere Bytefolge liefern. Prüfen Sie das Ergebnis und lassen Sie den Support einen betroffenen Anhang untersuchen, statt ein Kundendokument zu verändern oder anzunehmen, seine Metadaten belegten die Verfügbarkeit der Datei.

Das aktuelle Portal verwendet zuerst diese API-Route und verfügt über zusätzliche lokale Ausweichmechanismen. Ein erfolgreicher Download über das Portal beweist nicht, dass jeder Altdatensatz direkt über diese API heruntergeladen werden kann.

Fehler und Auswirkungen

Bei einem fehlenden, gelöschten oder nicht Ihrem Konto gehörenden Projekt wird der API-Code 404 mit der Meldung zurückgegeben, dass das Projekt nicht gefunden wurde. Bei einem fehlenden Upload innerhalb eines Ihrem Konto gehörenden Projekts wird der API-Code 404 mit der Meldung zurückgegeben, dass das Dokument nicht gefunden wurde. Lesen Sie neben dem HTTP-Status auch die Fehlerantworten der API. Für einen vorhandenen Datensatz ohne brauchbare gespeicherte Bytes gibt es in dieser Verarbeitungsfunktion keine eigene zuverlässige Antwort, die das Fehlen des Dokuments meldet.

Der geprüfte Endpunkt liest einen Anhang. Er lädt kein Dokument hoch, verändert oder entfernt keines, reicht keinen Portierungsauftrag ein und belastet das Konto nicht. Portierungsanhänge können Identitäts-, Abrechnungs- oder Vollmachtsinformationen enthalten: Verwenden Sie sie ausschließlich in autorisierten Kontoabläufen und nehmen Sie sie nicht in öffentliche Protokolle, Analysedaten oder Screenshots für die Dokumentation auf.