Apa yang diharapkan
Tujuannya adalah untuk menunjukkan kepada pengembang masalah apa yang dihadapi pengguna API mereka pada contoh bekerja dengan berbagai sistem CRM.
Untuk melindungi wajah saya, saya tidak akan mengiklankan nama-nama peserta dalam artikel ini.
Juga, saya - saya bukan programmer dari pacar ibu saya, jadi jangan mengambil kesimpulan saya untuk satu-satunya pilihan yang benar.
Eyeliner
Sekali waktu hiduplah seorang anak lelaki yang penuh harapan. Bocah ini tidak memiliki apapun dalam hidupnya kecuali bekerja dalam dukungan teknis dari program akuntansi. Dia memasak di kuali ini untuk waktu yang lama, sampai dalam satu hari, dia merobek atapnya, dan dia mengirim sifat tuan rumah utama dan pergi mencari prospek.
Bocah itu selalu bermimpi tentang bagaimana ia akan menjadi pengembang yang keren, ia akan mendapatkan uang yang luar biasa, terutama dalam mata uang Basurm. Dan oleh karena itu, sejalan dengan pekerjaannya, ia terlibat dalam pembuatan situsnya, menggunakan teknologi yang belum pernah terjadi sebelumnya, tetapi dengan fitur yang belum pernah terjadi selama bertahun-tahun. Berkat ini, ia dapat menemukan pemilik baru, yang memberinya pekerjaan di bisnis favoritnya, dengan gaji yang baik, dan dengan prospek yang tidak realistis.
Sejak itu, bocah itu hidup, hidup, dan menjadi baik. Dan dia tidak tahu masalah dan kesedihannya ... atau apakah dia tahu? Mari kita cari tahu!
Saya mendapat pekerjaan di perusahaan intelijen bisnis. Dan analitik seperti apa yang bisa tanpa data? Oleh karena itu, perusahaan memiliki tim terpisah, dan kemudian departemen yang terlibat dalam pengumpulan data dari situs pelanggan untuk membangun jadwal pendapatan dari saluran iklan dan sumber lainnya. Berbicara tentang hal spesifik, pekerjaan saya adalah menginstal penghitung kami di situs, untuk mengumpulkan data tentang pengunjung, dan membuat aplikasi dari formulir, obrolan online, panggilan balik, dll. dalam sistem CRM mereka. Di mana, di masa depan, analitik kami memperoleh informasi tentang status dan jumlah penjualan.
Dan tampaknya tidak ada yang rumit di sini, mengingat bahwa pembuatan aplikasi dalam CRM disederhanakan dengan membungkus sistem kami, yang, menggunakan 1 permintaan, membuat aplikasi dan klien, termasuk mengambil alih layanan pihak ketiga. Tetapi seperti yang harus Anda pahami, logika semacam itu tidak berbeda dalam fleksibilitas. Dan jika klien membutuhkan sesuatu yang tidak standar, maka sudah perlu untuk "mematikan mode kenyamanan" dan menyingsingkan lengan baju mereka untuk bekerja secara langsung dengan API dari sistem yang diinginkan. Dan kadang-kadang, bekerja dengan API bermasalah berikutnya,
saya pikir akan lebih baik tinggal di sana. mendukung ...
Masalah # 1: kurangnya metode / data
Mungkin masalah paling umum yang saya temui dalam hidup saya adalah kurangnya kemampuan untuk mendapatkan data yang saya butuhkan yang ada di antarmuka. Konflik dengan klien terus-menerus muncul dan terus muncul, karena kenyataan bahwa kita tidak bisa mendapatkan sesuatu yang mereka lihat di layar monitor mereka setiap hari.
Sebagai contoh, beberapa tahun yang lalu, klien yang agak besar datang kepada kami yang perlu menyimpan dalam file CRM yang dikirim klien dari formulir di situs. Tugas biasa, tetapi tidak ada kemungkinan implementasi, dan tidak sampai hari ini!
Kegagalan untuk klien tidak dapat diterima, dan pada akhirnya kami harus mengunggah file, meniru permintaan JS dari antarmuka.
Saya harus mengatakan bahwa CRM ini, otorisasi dalam API, juga mengizinkan dalam antarmuka, yang, bagi saya, adalah solusi yang agak aneh. Namun, berkat ini, kami tidak perlu meniru otorisasi yang biasa. Atau, apakah itu dikandung ...?Kasus lain dengan CRM yang sama terjadi belum lama ini. Itu perlu untuk bertanggung jawab atas manajer aplikasi yang saat ini aktif. Dan seperti yang sudah Anda pahami, API tidak mengembalikan informasi tentang aktivitas manajer kepada kami. Tetapi paradoksnya adalah bahwa API JS mereka kembali. Akibatnya, saya harus menulis aplikasi JS, semacam perantara, yang saya informasikan kepada server tentang manajer aktif saat ini.
Solusi:Di tim kami, sudah biasa membuat metode API publik untuk antarmuka, dan sudah berinteraksi dengan server melalui itu. Ini menghilangkan masalah ketidakcocokan antara kemampuan teknis antarmuka dan API publik.
Masalah nomor 2: kurangnya gaya permintaan / tanggapan yang seragam
Masalah yang sangat umum bahkan dalam CRM barat besar. Misalkan kita perlu mendapatkan daftar pesanan selama sebulan, kita mengetahui bahwa sistem memiliki batasan jumlah elemen dalam unggahan. Dan untuk menavigasi halaman Anda perlu menggunakan parameter ofset. Oke, kami telah menerapkan metode pemuatan pesanan, dan secara terpisah, metode paging tambahan.
Sekarang, kita perlu membongkar daftar klien, kita menerapkan metode baru bersama dengan metode pagination yang ditulis sebelumnya, dan ... kami mendapatkan kesalahan. Karena PM dan pengembang memutuskan bahwa offset suara terlalu mudah, sekarang biarkan vid-offset.
Tentu saja saya melebih-lebihkan, saya tidak tahu apa yang terjadi ketika mereka menulis api ini. Tapi ini setidaknya kesalahan PM, karena dia tidak menentukan bagaimana itu sudah diterapkan pada metode lain. Dan juga kesalahan pengembang, mereka yang menulis metode baru, dan mereka yang diperiksa. Untuk saat ini, semua orang yang menggunakan API mereka dipaksa untuk membangun kruk di aplikasi mereka.
Solusi:Metode api baru, jika mungkin, harus sesuai dengan struktur yang sudah ada. Pimpinan teknis (atau pemimpin tim karena kekurangan yang pertama) dapat menyusun peraturan, semacam gaya kode, yang menurutnya perlu untuk mengembangkan API, dan tanpa gagal membiasakan semua pengembang dengannya. Jika masalah sudah memiliki tempat untuk menjadi, maka, jika mungkin, lebih baik untuk menempatkan kruk di sisi Anda daripada memaksa ribuan pelanggan Anda untuk melakukannya di sisi Anda.
Masalah nomor 3: dokumentasi yang buruk atau kekurangannya
Dokumentasi adalah referensi pengembang. Kami sering menghadapi situasi ketika ditanya tentang kemungkinan penerapan fitur tertentu. Dan jika kita tidak ingat atau tidak tahu jawabannya, maka segera buka dokumentasinya. Untuk menemukan informasi di direktori yang baik adalah bekerja selama beberapa menit, sementara di direktori yang kelebihan beban Anda dapat menggali selama setengah jam, dan tetap saja Anda tidak akan mendapatkan jawaban yang pasti.
Dalam beberapa kasus tingkat lanjut, tidak mungkin menemukannya di domain publik. Dan jika Anda perlu mendapatkan daftar metode terbaru, Anda perlu menghubungi dukungan teknis. Dan kemudian Anda masih perlu memeriksa untuk melihat apakah sesuatu yang baru muncul di sana, bahwa kami meminta beberapa klien ...
Solusi:Saya akan memberikan beberapa poin yang, bagi saya, ciri dokumentasi kualitas:
- cari berdasarkan nama, deskripsi dan parameter metode
- deskripsi yang benar tentang tujuan metode ini
- daftar parameter yang diterima dengan jenis dan deskripsi
- daftar parameter yang dikembalikan dengan jenis dan deskripsi
- contoh permintaan
- contoh respon
- kode kesalahan mungkin dengan deskripsi
- kotak pasir di mana Anda dapat "bermain-main" dengan permintaan dalam mode desain
- ubah riwayat semua metode api untuk referensi cepat
Masalah nomor 4: sepeda otorisasi
Anda tahu perasaan luar biasa ini ketika Anda membuka dokumentasi sistem baru, dan di sana, di bagian otorisasi, urutan 3 metode dijelaskan untuk mendapatkan kunci yang valid hanya untuk 1 permintaan ...? Jadi, saya tidak memilikinya.
Bagi saya, mengapa masih ada pengembang yang meninggalkan Oauth 2.0 demi sepeda mereka? Dan oke, jika otorisasi terbatas pada satu token konstan, tetapi di sini adalah seluruh rantai otorisasi ...
Solusi:Anda tidak boleh menemukan kembali sepeda Anda ketika sudah ada standar siap pakai. Memang, untuk standar ini, pengembang sudah memiliki komponen sendiri untuk otorisasi sederhana.
Epilog
Saya berbicara tentang 4 masalah yang saya temui di awal perjalanan saya sampai hari ini. Saya mencoba memberikan solusi mereka, tetapi apakah mereka baik atau tidak adalah untuk Anda yang memutuskan. Pada akhirnya, masing-masing dari kita memiliki arsitektur pemikiran kita sendiri.
Jadi, saya berterima kasih kepada semua yang telah membaca sejauh ini! Ini adalah artikel pertama saya, dan jika memiliki nilai informasi untuk Anda, maka saya akan senang untuk melanjutkan serangkaian artikel tentang penderitaan saya dengan API.
Dan tentu saja, saya akan senang mendengar pendapat para pakar dalam komentar.
Semua dengan 2020 mendatang!