Saya bekerja sebagai pengembang di perusahaan Pusat Keuangan Elektronik JSC.
Salah satu proyek kami adalah Portal Pengadaan Publik Republik Kazakhstan - goszakup.gov.kz.
Setahun yang lalu, kami meluncurkan proyek besar - Unified Services (OpenData).
Untuk implementasi, metodologi RestAPI digunakan.
Hari ini saya akan berbicara tentang versi baru layanan kami dan antarmuka baru untuk bekerja dengannya.
Kami telah mengembangkan dan meluncurkan 6 layanan Data Terbuka:
- Daftar peserta
- Mendaftar pemasok yang tidak bermoral
- Daftar rencana tahunan
- Pengumuman negara. pengadaan
- Daftar Lot
- Daftar kontrak
Banyak perusahaan di Kazakhstan sudah menghubungkan dan menerima data pada layanan ini.
Peluncuran Open Data memungkinkan kami untuk mengurangi beban basis data sekitar 40% karena fakta bahwa perusahaan tidak perlu menulis parser yang berbeda untuk mengumpulkan data tentang Pengadaan Publik. Sudah cukup untuk menjalani pencarian yang sulit :)
- tulis permintaan untuk token akses
- baca dokumentasi untuk layanan di portal kami goszakup.gov.kz/ru/developer/ows
- tulis klien RestAPI Anda
Layanan Terpadu - Pendekatan Baru
RestAPI memungkinkan untuk mendapatkan data dengan lebih mudah dan cepat daripada mem-parsing sebuah situs, tetapi standar RestAPI tidak memberikan fleksibilitas kepada perusahaan dan untuk membangun koneksi dengan objek-objek Anda harus mendapatkan semua data terlebih dahulu dan baru kemudian membangun tautan di antara mereka.
Untuk menerima data tentang pengumuman, perlu oleh RestAPI untuk meminta terlebih dahulu daftar pengumuman, kemudian daftar lot dan akhirnya daftar rencana. Ini berarti bahwa untuk menerima satu pengumuman, perlu untuk menyelesaikan setidaknya 3 permintaan, dan jika Anda perlu menerima data pada 50 iklan, Anda akan memerlukan setidaknya 101 permintaan ke RestAPI, asalkan setiap pengumuman akan memiliki 1 lot (1 untuk menerima 50 iklan, 50 untuk menerima lot, 50 hingga menerima poin rencana).
Kami telah menemukan cara untuk mengurangi jumlah ini menjadi satu permintaan!
Kami meluncurkan versi 2 dari Layanan Terpadu -
ows.goszakup.gov.kz/v2 .
Selain memperluas kumpulan data, kami memperluas kemampuan untuk bekerja dengan API kami.
Sekarang data dapat diperoleh melalui RestAPI dan antarmuka baru - GraphQL.
ows.goszakup.gov.kz/v2/graphql
Saya tidak akan menjelaskan apa itu GraphQL, untuk ini Anda dapat membaca artikel
aliksend -
Apakah GraphQL ini?Saya akan memberi tahu Anda keuntungan apa yang kami dapatkan setelah memulai GraphQL:
- Meminta fleksibilitas;
- Mendapatkan objek terkait;
- Pengetikan lengkap permintaan dan tanggapan;
- Antarmuka pencarian data baru.
Minta fleksibilitas
Dengan permintaan RestAPI yang sederhana, Anda mendapatkan format data yang telah ditetapkan sebelumnya.
Ketika Anda meminta GraphQL, Anda mendapatkan data dalam format yang Anda butuhkan.
Saat meminta data, Anda sendiri yang menentukan format data yang Anda butuhkan, misalnya ID dan
Nomor kontrak
{ contract { id contract_number_sys } }
Sebagai tanggapan, kami hanya mendapatkan data ini:
{ "data": { "contract": [ { "id": 1, "contract_number_sys": "_" } ] } }
Nah, pertanyaan seperti itu adalah yang termudah untuk mengimplementasikan GraphQL. Perusahaan diberi kesempatan untuk memilih data apa yang ingin mereka terima, sementara kita tidak perlu melakukan penyesuaian seolah-olah ketika bekerja dengan RestAPI. Anda hanya mendapatkan set bidang yang diperlukan.
Mengambil Objek Terkait
Kami tidak berhenti mengulangi fungsionalitas RestAPI hanya dengan memungkinkan sebagian data dipilih.
Kami telah mengimplementasikan fitur 2 dari GraphQL - hubungan objek.
Jika Anda menerima data menurut RestAPI, untuk menerima data pada kontrak dan perusahaan, pelanggan dalam kontrak pertama-tama harus mendapatkan data dari
Daftar Peserta , dan hanya kemudian menerima data dari
Daftar Kontrak dan membangun koneksi antara objek itu sendiri.
Sekarang, ketika bekerja dengan GraphQL, Anda tidak perlu sepenuhnya menerima data dari Daftar Peserta, cukup minta data dalam format yang Anda minati:
{ contract { id contract_number_sys customer { name_ru } } }
Dengan demikian, dengan satu permintaan, kami mendapatkan data kontrak dan data perusahaan untuk pelanggan:
{ "data": { "contract": [ { "id": 1, "contract_number_sys": "_", "customer" : { "name_ru": " " } } ] } }
Dan ada banyak hubungan seperti itu yang telah diterapkan, sekarang perusahaan untuk menerima data akan membutuhkan lebih sedikit permintaan untuk data. Pada saat yang sama, orang tidak perlu lagi menebak dengan tepat bagaimana benda terkait satu sama lain, untuk menerima set data lengkap untuk menghubungkan mereka satu sama lain.
Saya mencoba menunjukkan sebagian struktur koneksi yang berhasil saya capai.
Mengetik permintaan dan tanggapan
Banyak pendukung permintaan SOAP selalu memasukkan plus - data yang paling penting.
RestAPI, tidak seperti SOAP, tidak memiliki deskripsi strukturnya dan Anda tidak tahu sebelumnya tipe data apa. Tapi GraphQL mengubah segalanya.
Sekarang Anda dapat meminta data dari GraphQL di seluruh skema data dan Anda akan menerima:
- Deskripsi lengkap tentang struktur data;
- Deskripsi bidang mana yang memiliki tipe data (Int, String, Boolean);
- Deskripsi objek bersarang dan struktur bidang objek bersarang;
- Deskripsi terperinci, misalnya, dalam bahasa Rusia untuk setiap bidang;
- Terima pemberitahuan bahwa beberapa bidang telah menerima bendera yang ditinggalkan dengan deskripsi.
Saya menggunakan program REST Client Insomnia - insomnia.rest untuk bekerja dengan
GraphQLSaat bekerja dengan GraphQL, ia menerima seluruh struktur objek dan meminta ketika membangun kueri.
Saya akan memberikan beberapa tangkapan layar sebagai contoh.
1. Bantuan dalam membangun kueri sejak itu program menerima struktur objek yang lengkap
2. Petunjuk untuk deskripsi masing-masing bidang dengan tipe data dan deskripsi
3. Petunjuk jika beberapa bidang menerima bendera - Sudah usang
Dan fitur GraphQL ini memungkinkan Anda untuk memiliki gambaran lengkap tentang bidang dan objek yang Anda gunakan.
Antarmuka pengambilan data baru
Dan saya meninggalkan yang paling menarik pada akhirnya.
Semuanya tampak keren, dimungkinkan untuk membangun struktur data Anda sendiri, ada koneksi dengan objek lain, semua data diketik. Tapi masih ada yang hilang ...
Tidak ada cukup kesempatan untuk mencari data ini.
Sejak awal, format pencarian diimplementasikan dengan parameter dalam permintaan itu sendiri:
{ trd_buy(ref_buy_status_id: 1) { name_kz name_ru } }
Tapi di sini saya mengalami sejumlah masalah:
- dengan sejumlah besar kriteria pencarian, kueri menjadi tidak dapat dibaca;
- tidak mungkin untuk menentukan array ketika mencari data untuk mencari beberapa varian dari bidang yang sama.
Untuk menyederhanakan konstruksi kueri, dan untuk memperluas kemampuan pencarian, saya menerapkan objek bersarang untuk memfilter data.
Kami mendefinisikan variabel dalam permintaan yang menunjukkan objek pemfilteran.
query($filter: TrdBuyFiltersInput){ trd_buy(filters: $filter) { name_kz name_ru } }
Kami menggambarkan sendiri parameter pencarian data:
{ "filter": { "ref_buy_status_id": [1, 2] } }
Dan sebagai hasilnya, kami akan menerima semua iklan yang memiliki status 1 dan 2.
Dalam permintaan itu sendiri, kami hanya menunjukkan struktur data, dan semua parameter pencarian masuk ke transmisi parameter di mana kami sudah dapat mentransfer array data untuk penyaringan sesuai dengan beberapa kriteria.
Selain itu, dalam skema GraphQL itu sendiri, kita juga memiliki deskripsi objek pencarian seperti itu:
Layanan Terpadu - Versi 2.0:
Layanan bekerja:
- Daftar peserta
- Daftar pengumuman
- Daftar kontrak
- Daftar tindakan
- Daftar Lot
- Daftar rencana tahunan
- Mendaftar pemasok yang tidak bermoral
Kami meluncurkan fungsionalitas baru yang sangat menyederhanakan pekerjaan dengan API kami, memiliki struktur kueri yang fleksibel dan kemampuan untuk mencari data sesuai dengan kriteria yang ditentukan.
Kami tidak kehilangan kecepatan dalam mendapatkan data, tetapi hanya mengurangi karena ini jumlah permintaan yang diperlukan untuk mendapatkan data.
Kami dapat memperingatkan dalam skema data tentang bidang yang dinonaktifkan atau diganti namanya.
Kami berencana untuk mengembangkan API lebih lanjut dan memungkinkan pencarian data morfologis layanan juga.