Unified Services goszakup.gov.kz - Version 2

Ich arbeite als Entwickler in der Firma Center for Electronic Finance JSC.
Eines unserer Projekte ist das Portal für das öffentliche Beschaffungswesen der Republik Kasachstan - goszakup.gov.kz.

Vor einem Jahr haben wir ein großes Projekt gestartet - Unified Services (OpenData).
Für die Implementierung wurde die RestAPI-Methodik verwendet.

Heute werde ich über die neue Version unserer Dienste und die neue Schnittstelle für die Arbeit mit ihnen sprechen.



Wir haben 6 Open Data-Dienste entwickelt und eingeführt:

• Teilnehmerregister
• Register skrupelloser Lieferanten
• Register der Jahrespläne
• Ankündigungen des Staates. Beschaffung
• Losregister
• Registrierung von Verträgen

Viele Unternehmen in Kasachstan verbinden und empfangen bereits Daten zu diesen Diensten.
Durch die Einführung von Open Data konnten wir die Datenbanklast um etwa 40% reduzieren, da Unternehmen keine unterschiedlichen Parser schreiben müssen, um Daten zum öffentlichen Beschaffungswesen zu sammeln. Es ist genug, um eine schwierige Aufgabe zu bestehen :)

1. Schreiben Sie eine Anfrage für ein Zugriffstoken
2. Lesen Sie die Dokumentation für Services auf unserem Portal goszakup.gov.kz/ru/developer/ows
3. Schreiben Sie Ihren RestAPI-Client

Unified Services - Ein neuer Ansatz

RestAPI ermöglicht es, Daten bequemer und schneller abzurufen als das Parsen einer Site. Das Standard-RestAPI bietet Unternehmen jedoch keine Flexibilität. Um eine Verbindung mit Objekten herzustellen, müssen Sie zuerst alle Daten abrufen und erst dann die Verknüpfungen zwischen ihnen herstellen.
Um Daten in einer Anzeige zu erhalten, muss RestAPI zuerst das Ankündigungsregister, dann das Losregister und schließlich das Planregister anfordern. Dies bedeutet, dass zum Erhalt einer Ankündigung mindestens 3 Anfragen ausgeführt werden müssen. Wenn Sie Daten zu 50 Anzeigen erhalten möchten, benötigen Sie mindestens 101 Anfragen an RestAPI, vorausgesetzt, jede Ankündigung enthält 1 Los (1 zum Empfangen von 50 Anzeigen, 50 zum Empfangen von Losen, 50 zu Erhalt von Planpunkten).

Wir haben einen Weg gefunden, diesen Betrag auf eine Anfrage zu reduzieren!

Wir starten die 2. Version von Unified Services - ows.goszakup.gov.kz/v2 .
Neben der Erweiterung von Datensätzen erweitern wir die Möglichkeit, mit unserer API zu arbeiten.

Jetzt können die Daten über RestAPI und die neue Schnittstelle - GraphQL - abgerufen werden.
ows.goszakup.gov.kz/v2/graphql



Ich werde nicht beschreiben, was GraphQL ist, dazu können Sie den Artikel aliksend lesen - Was ist das GraphQL?

Ich werde Ihnen sagen, welche Vorteile wir nach dem Start von GraphQL haben:

• Flexibilität anfordern;
• Verwandte Objekte abrufen;
• Vollständige Eingabe von Anfragen und Antworten;
• Neue Datensuchoberfläche.

Flexibilität anfordern

Mit einer einfachen RestAPI-Anfrage erhalten Sie das Datenformat, das im Voraus festgelegt wurde.
Wenn Sie GraphQL abfragen, erhalten Sie die Daten in dem Format, das Sie benötigen.

Wenn Sie Daten anfordern, bestimmen Sie selbst das Format der Daten, die Sie benötigen, z. B. die ID und

Vertragsnummer

{ contract { id contract_number_sys } } 

Als Antwort erhalten wir nur diese Daten:

 { "data": { "contract": [ { "id": 1, "contract_number_sys": "_" } ] } } 

Nun, solche Abfragen sind am einfachsten zu implementieren. Unternehmen haben die Möglichkeit zu wählen, welche Daten sie erhalten möchten, während wir keine Anpassungen vornehmen müssen, als ob dies bei der Arbeit mit RestAPI der Fall wäre. Sie erhalten nur die erforderlichen Felder.

Verwandte Objekte abrufen

Wir haben nicht aufgehört, die Funktionalität von RestAPI zu wiederholen, indem wir einfach die teilweise Auswahl von Daten ermöglicht haben.

Wir haben die zweite Funktion von GraphQL - Objektbeziehungen implementiert.

Wenn Sie Daten gemäß RestAPI erhalten, muss der Kunde im Vertrag, um Daten zum Vertrag und zum Unternehmen zu erhalten, zunächst Daten aus dem Teilnehmerregister abrufen und erst dann Daten aus dem Vertragsregister empfangen und die Verbindung zwischen den Objekten selbst herstellen.

Wenn Sie mit GraphQL arbeiten, müssen Sie keine Daten mehr vollständig aus dem Teilnehmerregister empfangen. Fordern Sie einfach Daten in dem Format an, an dem Sie interessiert sind:

 { contract { id contract_number_sys customer { name_ru } } } 

So erhalten wir mit einer Anfrage sowohl Vertragsdaten als auch Unternehmensdaten für den Kunden:

 { "data": { "contract": [ { "id": 1, "contract_number_sys": "_", "customer" : { "name_ru": " " } } ] } } 

Und es gibt viele solcher Beziehungen, die implementiert wurden. Jetzt benötigen Unternehmen, um Daten zu erhalten, erheblich weniger Datenanforderungen. Gleichzeitig muss man nicht mehr genau erraten, wie Objekte zueinander in Beziehung stehen, um vollständige Datensätze zu erhalten, um sie miteinander zu verbinden.

Ich habe versucht, die Verbindungsstruktur, die ich erreicht habe, teilweise zu demonstrieren.

Anfragen und Antworten eingeben

Viele Befürworter von SOAP-Anfragen haben immer das wichtigste Plus gesetzt - die Datentypisierung.
RestAPI hat im Gegensatz zu SOAP keine Beschreibung seiner Struktur und Sie wissen nicht im Voraus, welcher Datentyp. Aber GraphQL ändert alles.

Jetzt können Sie im gesamten Datenschema Daten von GraphQL anfordern und erhalten:

• Vollständige Beschreibung der Datenstruktur;
• Beschreibung, welches Feld einen Datentyp hat (Int, String, Boolean);
• Beschreibung verschachtelter Objekte und Feldstruktur verschachtelter Objekte;
• Detaillierte Beschreibung zum Beispiel in russischer Sprache für jedes Feld;
• Erhalten Sie eine Benachrichtigung, dass ein Feld das Flag Veraltet mit einer Beschreibung erhalten hat.

Ich verwende das Insomnia REST Client-Programm - insomnia.rest, um mit GraphQL zu arbeiten
Bei der Arbeit mit GraphQL erhält es die gesamte Struktur von Objekten und fordert beim Erstellen einer Abfrage dazu auf.

Ich werde ein paar Screenshots als Beispiel geben.

1. Hilfe beim Erstellen von Abfragen seit Das Programm erhielt eine vollständige Objektstruktur



2. Hinweis zur Beschreibung jedes Feldes mit Datentyp und Beschreibung



3. Hinweis, wenn ein Feld ein Flag erhalten hat - Veraltet



Mit dieser Funktion von GraphQL erhalten Sie ein vollständiges Bild davon, mit welchen Feldern und Objekten Sie arbeiten.

Neue Datenabrufschnittstelle

Und am Ende habe ich das interessanteste verlassen.

Alles scheint cool zu sein, es ist möglich, eine eigene Datenstruktur aufzubauen, es besteht eine Verbindung zu anderen Objekten, alle Daten werden eingegeben. Aber es fehlt noch etwas ...

Es gibt nicht genügend Gelegenheit, nach diesen Daten zu suchen.

Von Anfang an wurde ein Suchformat mit den Parametern in der Anfrage selbst implementiert:

 { trd_buy(ref_buy_status_id: 1) { name_kz name_ru } } 

Aber hier bin ich auf eine Reihe von Problemen gestoßen:

1. Bei einer großen Anzahl von Suchkriterien wird die Abfrage einfach unlesbar.
2. Es ist unmöglich, das Array bei der Suche nach Daten zu bestimmen, um nach mehreren Varianten desselben Feldes zu suchen.

Um die Erstellung von Abfragen zu vereinfachen und die Suchfunktion zu erweitern, habe ich verschachtelte Objekte zum Filtern von Daten implementiert.

Wir definieren eine Variable in der Anfrage, die das Filterobjekt angibt.

 query($filter: TrdBuyFiltersInput){ trd_buy(filters: $filter) { name_kz name_ru } } 

Wir beschreiben die Datensuchparameter selbst:

 { "filter": { "ref_buy_status_id": [1, 2] } } 

Als Ergebnis erhalten wir alle Anzeigen mit den Status 1 und 2.

In der Anfrage selbst geben wir nur die Datenstruktur an, und alle Suchparameter fließen in die Übertragung von Parametern ein, bei denen wir bereits Datenarrays zur Filterung nach mehreren Kriterien übertragen können.



Darüber hinaus haben wir alle im GraphQL-Schema selbst eine Beschreibung eines solchen Suchobjekts:

Unified Services - Version 2.0:

Dienstleistungen arbeiten:

• Teilnehmerregister
• Registrierung von Ankündigungen
• Registrierung von Verträgen
• Register der Handlungen
• Losregister
• Register der Jahrespläne
• Register skrupelloser Lieferanten

Wir haben eine neue Funktionalität eingeführt, die die Arbeit mit unserer API erheblich vereinfacht, über eine flexible Abfragestruktur verfügt und die Möglichkeit bietet, nach festgelegten Kriterien nach Daten zu suchen.

Wir haben nicht an Geschwindigkeit beim Abrufen von Daten verloren, sondern nur die Anzahl der zum Abrufen von Daten erforderlichen Anforderungen verringert.

Wir konnten im Datenschema vor deaktivierten oder umbenannten Feldern warnen.

Wir planen, die API weiterzuentwickeln und auch die morphologische Suche nach Daten zu Diensten zu ermöglichen.