Geekly articles weekly

Kisah satu API: bagaimana kami mengubah Frankenstein menjadi tampan

Apa yang dibutuhkan untuk membangun ekosistem layanan non-perbankan, dan memang ekosistem serupa lainnya? Sistem master untuk menyimpan dan memproses data, serta API. Dalam posting ini, kita akan menganalisis dua versi API yang kami buat - yang pertama dan yang paling sukses - dan membahas apa perbedaan penting mereka satu sama lain.



Untuk menciptakan ekosistem layanan non-perbankan, produk utama dari divisi Sberbank Digital Corporate Bank dipilih - bank Internet untuk klien korporat Sberbank Business Online. Oleh karena itu, API fintech untuk ekosistem layanan non-perbankan juga dibuat atas dasar itu.

Versi pertama API fintech diluncurkan pada tahun 2016. Itu dibuat dengan memperhatikan API kami yang lain dari bank kami, menurut resep klasik API organisasi keuangan besar. Berikut bahan utamanya:

  • Protokol SOAP untuk transfer data
  • Format XML
  • Tanda tangan elektronik semua permintaan
  • Operasi asinkron
  • Perangkat keras-VPN yang diperlukan untuk saluran aman
  • Otentikasi eksklusif dan sistem otorisasi
  • Format yang ditetapkan secara historis untuk mentransfer informasi keuangan (misalnya, format perbankan langsung 1C)

Kami membuat keputusan seperti itu dan memulai integrasi percontohan dengan beberapa layanan perbankan non-klasik: toko online Evotor, sistem manajemen keuangan Business Analytics Seeneco, akuntansi berbasis cloud MyOdelo, dan lainnya.

Hasil integrasi jauh dari yang diinginkan. Dari API layanan non-keuangan modern, para mitra sama sekali tidak mengharapkan apa yang biasa dalam pengembangan produk perbankan klasik. Kami ingin mendapatkan sesuatu yang mirip dengan API dari raksasa internet modern: Facebook, Google, Yandex.

Dan pada akhirnya, mereka menemukan API bank klasik - berat, tidak jelas, membutuhkan keterampilan tinggi dan spesifik, memahami seluk-beluk proses kerja, menerapkan persyaratan keamanan yang berlebihan ... secara umum, banyak hal yang mengarah pada pelanggaran semua tenggat waktu integrasi yang mungkin.

Kami menganalisis pengalaman ini dan memutuskan untuk membuat versi baru API fintech dari awal. Untuk mendapatkan win-win maksimum dengan layanan non-keuangan pihak ketiga, persyaratan paling penting dijelaskan sebelumnya:

  • Tidak ada format universal dan berat yang memperhitungkan nuansa sedikit pun. Ayo lebih mudah!
  • API harus sesuai dengan jangkauan seluas mungkin dari mitra potensial yang menawarkan produk non-keuangan kepada pelanggan Sberbank. Sampai diperkenalkannya kulkas pintar - apa yang tidak bercanda.
  • API perlu dirancang menggunakan praktik dan metode yang digunakan untuk membuat antarmuka visual. Untuk melakukan ini, Anda perlu mengidentifikasi dan menganalisis skema UX untuk menggunakan API. Mengikuti kanon klasik jelas tidak sepadan.
  • Kita perlu menyingkirkan deskripsi multi-volume sehingga pengembang dapat mencapai hasil cepat. Menggunakan kotak pasir untuk uji coba, Anda perlu mendapatkan hasil positif pertama dalam satu jam.
  • Kami menolak solusi eksklusif yang terkait dengan platform spesifik sebanyak mungkin. Semuanya harus lintas platform dan tidak membatasi mitra dalam infrastruktur yang digunakan dan lingkungan pengembangan.
  • Mitra tidak boleh terganggu oleh apa yang tidak mereka lakukan - struktur data yang kompleks, mekanisme komponen platform perbankan, dan fitur sistem warisan kami. Kami bersembunyi dan tidak mengubur kepala mereka.

Dengan daftar ini, kami beralih ke implementasi dan solusi yang dipilih untuk versi kedua API fintech:

  • Otentikasi berbasis OAUTH 2.0
  • Arsitektur REST melalui HTTP tanpa kompleksitas tambahan
  • Operasi yang sepenuhnya sinkron
  • Format JSON
  • Penggunaan tanda tangan elektronik opsional - jika perlu
  • Tes kotak pasir dengan SWAGGER yang digunakan. Menggunakan lingkungan debugging ini, pengembang mitra dapat mensimulasikan alur kerja bisnis dan mendapatkan hasil tanpa menulis kode
  • Menerapkan Pendekatan Langkah-Langkah Mudah yang Digunakan oleh Startups Internet untuk Membuat Dokumentasi API
  • Praktek Agile Pengembangan API - Hasil Cepat dan Pengumpulan Umpan Balik

Sebenarnya apa yang telah berubah


Untuk menilai perbedaan antara dua versi API, kami membandingkan implementasi dari tiga komponen utamanya: otorisasi, penerapan perintah pembayaran rubel, dan tanda tangan elektronik.

Di versi pertama API, untuk otorisasi, mitra membutuhkan nama pengguna dan kata sandi, sertifikat, dan AccessToken, yang diperoleh sebagai hasil otentikasi OAUTH dari klien yang mengajukan:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:upg="http://upg.sbns.zzzzz.com/">   <soapenv:Header/>   <soapenv:Body>      <upg:preLogin>         <!--Optional:-->         <upg:userLogin>U1</upg:userLogin>         <!--Optional:-->         <upg:changePassword>!d63NvJ+Sa</upg:changePassword>      </upg:preLogin>   </soapenv:Body> </soapenv:Envelope>

Di API 2.0, otorisasi menjadi jauh lebih ringkas. Untuk mengakses layanan, Anda hanya perlu AccessToken yang diterima selama otentikasi OAUTH klien:

 { "access_token": "fdba5482-460c-4535-b829-9fd836fd01f0-1", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "7f545a14-ab7b-45ff-823a-0421e9f3b42e-1", }

Di API 1.0, bekerja dengan pesanan pembayaran rubel juga didasarkan pada SOAP:

 <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:upg="http://upg.sbns.zzzzz.com/">  <soapenv:Header/>  <soapenv:Body>     <upg:sendRequestsSRP>        <!--Zero or more repetitions:-->        <upg:requests><![CDATA[       <Request xmlns='http://zzzzz.com/upg/request' orgId='84b70f22-703f-bf04-db60-bd110572f40d' requestId='a81ddc6d-fb92-416d-83f9-6785a59a4b17' version='1.0' sender='PARTNER' clientOrgIdHash='ee0fb56b01a9d9b9648a2c60549b77702eb2a6de8f2189c4349447e43b250da5' clientAccessToken='ee0fb56b01a9d9b9648a2c60549b77702eb2a6de8f2189c4349447e43b250da5-1'> <PayDocRuInvoice docExtId='a81decfd-fb92-416d-83f9-6785a59abb65' orderNum='62' deadLine='2017-04-10T17:16:03'> <PersonalAcc>40802810000000000000</PersonalAcc> <AccDoc docDate='2017-02-15' docSum='777' transKind='01' paytKind='01' priority='1'> <Purpose>!!!!! 18%</Purpose> </AccDoc> </PayDocRuInvoice> </Request>        ]]></upg:requests>        <!--Optional:-->        <upg:sessionId>5a869c00-e979-4280-b11a-6dbbb8a90214</upg:sessionId>     </upg:sendRequestsSRP>  </soapenv:Body> </soapenv:Envelope>

Di API 2.0, dengan cara yang serupa, semuanya menjadi lebih sederhana dan lebih mudah dipahami:

 {  "amount": 12.01,   "date": "2018-06-22",   "deliveryKind": "",   "expirationDate": "2018-06-23",   "externalId": "1516ec0c-761c-11e8-adc0-fa7ae01bbebc",  "operationCode": "01",  "orderNumber": "1237",   "payeeAccount": "40706810000000000000",   "paymentNumber": "1",  "priority": "5",   "purpose": "  №1237.   .",  "urgencyCode": "NORMAL",   "vat": {    "amount": 100.01,     "rate": "7",     "type": "NO_VAT" }

Kami juga memfasilitasi tanda tangan elektronik. Inilah yang terjadi di API 1.0.


Jadi permintaan itu tampak


Berikut adalah daftar atribut


Dan sekarang tanda tangan selesai

Di API 2.0, semuanya lebih mudah melalui JSON:


Minta sendiri


Tanda tangan sebagai hasilnya

Ringkasan


Peluncuran pilot fintech API 2.0 menunjukkan bahwa segalanya berjalan lebih baik. Waktu integrasi dengan produk mitra - dari awal kerja hingga saat rilis ke dalam operasi komersial - berkurang lebih dari 3 kali lipat. Jumlah pertanyaan untuk layanan pendamping kami telah dikurangi dengan urutan besarnya, dan yang paling penting, kompleksitas masalah ini telah berkurang. Akhirnya, jumlah pengaduan tentang kompleksitas dan ketidakpastian API berkurang dua kali lipat. Secara umum, kami berhasil. Jika Anda memiliki pertanyaan, selamat datang di komentar, dengan senang hati kami akan memberitahukan detailnya kepada Anda.

Materi disiapkan oleh Andrey Khokhlov, Manajer Proyek, Digital Corporate Bank Sberbank

Source: https://habr.com/ru/post/id421693/

More articles:


All Articles