Pendahuluan
Tentang saya
Halo semuanya, saya adalah siswa biasa dalam spesialisasi "teknisi perangkat lunak." Sejak kecil saya sangat menyukai komputer, sejak kelas 7 saya mulai belajar pemrograman itu sendiri. Saya telah menjadi pemilik langganan Yandex Music selama lebih dari satu tahun dan saya umumnya puas dengan layanan ini (meskipun sekarang ada pengulangan yang terus-menerus dalam daftar putar hari itu).
Latar belakang
Saya tidak ingat persis mengapa saya memutuskan untuk mencari dokumentasi API resmi untuk layanan ini, seperti bot yang ingin saya tulis untuk Telegram, tetapi saya menemukan fakta bahwa itu bukan ... Setelah beberapa waktu saya menemukan masalah dalam repositori yandex / audio-js . Di sana, mereka mengajukan pertanyaan yang sama persis dengan saya: "Di mana API?" Tidak banyak orang yang ingin mendengarkan musik melalui browser, mereka menginginkan aplikasi, tetapi tidak ada aplikasi Linux juga! Mengintegrasikan ke pemain favorit Anda tidak mungkin!
Lalu saya mendapat ide untuk melakukannya. Tentu saja, saya perlu bekerja dengan layanan ini, membuat kruk di sekitar aplikasi web bukan pilihan. Saya mengerti bahwa memiliki layanan seperti itu, memiliki aplikasi seluler dan aplikasi untuk Windows (dari Microsoft Store), tidak mungkin untuk tidak memiliki API internal Anda sendiri untuk berinteraksi. Aku benar!
Bacaan wajib sebelum tubuh utama
Saya menyadari bahwa, dengan mempelajari API non-publik mereka, saya mencari-cari hal-hal kotor orang lain. Di bawah ini akan diuraikan berbagai masalah kontroversial, keputusan pengembang dan, secara umum, bagaimana mereka menulisnya dan bagaimana mereka menggunakannya. Di beberapa tempat saya hanya terkejut , tetapi saya yakin jika mereka melakukannya, maka ada alasan untuk itu ! Jangan lupa bahwa tidak ada yang seharusnya melihat ini. Saya juga ingin mengatakan bahwa semua yang ditulis di bawah ini adalah pendapat saya . Anda bisa setuju dengannya atau tidak.
Tubuh utama
Persiapan
API aplikasi web
Di atas, saya sudah menulis bahwa saya menemukan API. Sama sekali tidak sulit. Pertama-tama, saya melihat aplikasi web mereka, titik akhir mereka pada saat penulisan ada di sini: https://music.yandex.ru/api/v2.1/
. Mereka memiliki url yang cukup panjang di mana saya berpartisipasi dalam data, dan mereka juga mengirim formulir. Saya juga meminta Anda untuk memperhatikan menunjukkan versi API , itu.
Anda perlu memahami bahwa apa yang saya temukan hanya digunakan oleh mereka dalam aplikasi web. Tidak ada OAuth. Lebih tepatnya, itu lebih mungkin ada, tetapi di sana, di perut sesi kami di situs. Secara umum, perpustakaan tidak cocok sehubungan dengan kruk dalam otorisasi.
API aplikasi
Saya berangkat untuk mencari lebih jauh. Saya terlalu malas untuk mengambil telepon, oleh karena itu, saya akan mendapatkan aplikasi seluler yang terakhir. Saat itu, komputer menjalankan Windows 10, dan saya aktif menggunakan aplikasi Yandex Music resmi dari Microsoft Store . Akibatnya, saya mulai mempelajari cara kerjanya.
Untuk penelitian, saya memerlukan sniffer untuk melacak semua lalu lintas aplikasi. Anda bisa menggunakan Wireshark , tetapi saya memilih HTTP Analyzer . Menurut saya, ini lebih ringan dan sangat cocok untuk tugas saya.
Nyalakan sniffer, buka aplikasi dan selesai. Permintaan mengalir demi arus. Kami duduk, memahami, mencoba memanggil setiap penangan yang ada di aplikasi ini dan mencari tahu tentang semua metode yang ada, argumen mereka dan, tentu saja, jawaban JSON .

Dari tangkapan layar di atas, Anda dapat segera melihat alamat API yang sama sekali berbeda - api.music.yandex.net
. Apalagi perhatikan judulnya. Selain informasi tentang klien saya dari mana permintaan itu dibuat, ada token OAuth - itulah yang Anda butuhkan!
API Pembelajaran
Penelitian berlangsung bersamaan dengan penulisan kode. Saya menulis kelas pembungkus untuk objek layanan yang diterima dari API, menerapkan permintaan pengiriman, mengurutkan parameter dan di beberapa tempat hanya menebak apa arti nama ini. Pada tahap ini, saya bertemu berbagai hal yang tidak saya harapkan untuk dilihat di sini.
Pada saat penulisan, perpustakaan berisi 83 kelas, dan hanya beberapa dari mereka yang merupakan pelengkap. Sisanya adalah kelas Musik Yandex, yang menunjukkan skala layanan ini dan tingkat abstraksi.
Mengirim ~ 47 metode telah diterapkan. Dan ini tidak semua yang ada di API (lebih lanjut tentang itu di bawah).
Nyeri
Pada awalnya, saya berusaha untuk tidak memperhatikan, saya hanya terkejut, karena ini Yandex , bagaimana mungkin. Tetapi kemudian, pada suatu saat yang baik, semuanya dibom. Saya akan mulai, mungkin, dengan dia.
Dua objek dengan berbagai tingkat lampiran bidang

Objek itu sendiri hanyalah "referensi" untuk dirinya sendiri. Untuk versi lengkapnya. Saat meminta daftar trek, kami diberi ID mereka, yang dengannya kami bisa mendapatkan informasi lebih rinci. Praktek yang baik, banyak yang melakukannya, tetapi itu tidak selalu dihormati (paragraf 9).

Setelah menerapkan kelas untuk objek ini di awal, saya berpikir bahwa saya akan menggunakannya di mana-mana, tetapi tidak peduli bagaimana caranya! Bagi saya sepertinya komentar itu berlebihan dan semuanya bisa dilihat di screenshot.
Saya tidak memperbaiki jenis tiang TrackShort
di perpustakaan saya, sehingga memiliki kelas TrackShort
sekarang memiliki TrackShortOld
.
Ngomong-ngomong, kedua objek ini hidup dalam metode yang sama, dalam metode landing'a .
Versi API, metode
Saya tidak hanya meminta Anda memperhatikan bagaimana versi tersebut ditentukan dalam API untuk aplikasi web. Secara umum, bagaimana biasanya kita menunjukkan versi? Mungkin dengan salah satu cara berikut:
- buat versi di subdomain terpisah;
- letakkan versi di bagian permintaan;
- meneruskan versi parameter API yang diinginkan ke permintaan.
Yandex memutuskan dalam hal ini untuk melakukan sebaliknya. Kami memiliki metode landing3 - versi saat ini pada saat penulisan. Tapi tidak ada yang melarang mengirim permintaan untuk pendaratan2 - struktur yang sama sekali berbeda, objek lainnya.
Saya menemukan ini secara tidak sengaja, hanya lupa menambahkan nomor di akhir nama metode dan menangkap banyak pengecualian.
Bekerja dengan yang baru, jangan menyerah pada yang lama
Saya melihat ini ketika saya menulis metode pengiriman "Suka" untuk semua objek yang ada. Sebenarnya tidak banyak dari mereka (daftar putar, artis, trek, album). Apa yang mengejutkan saya ketika saya melihat pendekatan berbeda untuk tindakan yang sama.
Kami menyukai artis seperti ini: https://api.music.yandex.net/users/<USER_ID>/likes/artists/add
dan transfer artist-id
dalam formulir.
Kami menyukai trek seperti ini: https://api.music.yandex.net/users/<USER_ID>/likes/tracks/add-multiple
dan dalam bentuk track-ids
.
Jika Anda belum memperhatikan, maka saat Anda menyukai trek, metode add-multiple digunakan, bukan add . Metode ini tidak digunakan dengan tipe lain, tetapi semuanya ada (layak hanya mencoba mengirim permintaan)! Dan saya menerapkannya di perpustakaan saya alih-alih menambahkan . Bagaimanapun, metode ini bersifat universal. Anda dapat menambahkan satu trek atau beberapa.
Apa itu pengenal trek yang unik
Banyak waktu telah berlalu, tetapi saya masih tidak mengerti kapan harus mengirim hanya id
lagu, dan kapan id dan album_id digabungkan melalui titik dua ( id:album_id
). Terkadang sebuah lagu ada di beberapa album, terkadang tidak ada album. Kasus-kasus yang terlalu jelas terlihat dari samping, saya tidak tahu bagaimana mereka menangani hal ini (atau tidak bisa melakukannya, bagus 2).
Banyak bidang opsional
Saya punya beberapa masalah. Jika ada masalah, maka itu terkait dengan bidang yang wajib diisi. Saya tidak pernah berhenti terkejut bagaimana, menurut pendapat saya, bidang yang diperlukan tidak mengembalikan API.
- album_id dari kelas TrackID dan TrackShort;
- order_id dari kelas AutoRenewable (berlangganan);
- next_revision di Umpan;
- cover_uri di Track;
- ulang tahun di Akun;
- tag di daftar putar.
Daftar berjalan, tetapi semuanya ada dalam sejarah komit. Mungkin item ini tersedot keluar dari jari.
Metode kesamaan kecuali untuk beberapa bidang dalam jawaban
Respons status akun ( api.music.yandex.net/account/status
):

Status akun radio respons ( https://api.music.yandex.net/rotor/account/status
):

Saya mengerti bahwa haknya berbeda, bidang sekarang dengan batas tidak pada jumlah trek dalam cache, tetapi pada jumlah lompatan per jam, tetapi lebih mirip semacam duplikasi.
Saya tidak tahu caranya di Yandex, tapi saya menggabungkannya menjadi satu kelas.
Jadi satu atau banyak?
Saya selalu berpikir bahwa jika suatu metode mengembalikan daftar, maka bahkan jika hasilnya adalah satu elemen, maka daftar yang mengandung elemen ini akan dikembalikan dan tidak ada yang lain, tetapi di sini dan kemudian, dan banyak lagi.

Fitur itu akan kembali, lalu fitur , lalu fitur dan fitur .
Penyalahgunaan metode
Di atas, saya menulis bahwa mereka menggunakan satu atau metode lain untuk melakukan satu tindakan. Mereka melangkah lebih jauh.

Selain ID daftar putar dan bingkai dengan dan dengan mana trek untuk menghapus, mereka karena alasan tertentu mengirimkan trek yang akan dihapus dengan metode menghapus trek dari daftar putar. Mungkin saja saya tidak mengerti ini, seperti yang lainnya, tetapi metode ini bekerja tanpa terlalu banyak informasi. Dan lagu apa yang dihapus, lebih baik mencari tahu di belakang, daripada melewati parameter.
Permintaan yang sangat berat
Saya menulis di atas bahwa memberikan daftar dengan ID trek adalah praktik yang baik, Anda mendapatkan informasi rinci tentang trek hanya ketika Anda benar-benar membutuhkannya. Ini tidak selalu digunakan di sini.
Lihatlah bagaimana tanpa ampun mereka memberikan informasi terperinci tentang semua lagu saya dari daftar putar "Suka" dalam satu permintaan:

Itu memberi semua 396 lagu ! Bytes Diterima: 3,75M , dan ini adalah unduhan sampul lain!
Baguette
Unduh semua trek ke cache dari "Suka"
Ketika batas tercapai, tambahan dibuat sampai akhir dan dihapus dari awal. Terima kasih untuk visualisasi antrian, tetapi saya pikir saya hanya akan mengunduh 100 lagu terakhir dari daftar putar. Ini terjadi pada klien seluler untuk Android ( menonton video ).
Sepertinya saya tidak bingung ketika saya perlu mengirim id, tetapi ketika id: album_id

Catatan
Jumlah upaya untuk mengaktifkan kode hadiah adalah 10. Larangan berikutnya selama 24 jam.
Bergantung pada aplikasi tempat Anda duduk, berbagai penawaran dibuat agar Anda dapat berlangganan.
Batas jumlah trek dalam cache adalah ilusi, itu hanya angka, dan aplikasi tidak memungkinkan Anda memuat lebih banyak (bagus 2).
Semua daftar putar, saran, teks, dan warna tombol pandai ini berasal dari API - ini dia, RESTFull asli.
Waktu mulai iklan dan iklan itu sendiri akan dikembalikan bahkan jika Anda berlangganan.
Tautan ke XML yang berisi data tentang lokasi file yang akan diunduh berlangsung 1 menit, kemudian 410 kesalahan.
Kesimpulan
Saya hanya menulis apa yang saya ingat. Bagaimanapun, saya menemukan semua ini selama beberapa bulan. Semua catatan saya adalah pesan dalam telegram, karena ketika saya menemukan sesuatu seperti itu, saya berbagi dengan teman-teman. Saya mencoba mengembalikan poin-poin utama.
Sama sekali tidak saya ingin mengatakan betapa buruknya segalanya, entah bagaimana menempatkan kusen pada publik khusus. Mungkin ini bukan kusen sama sekali, tetapi semua yang saya tulis di atas tampak aneh bagi saya secara pribadi .
Dia membagikan kepada Anda bagaimana ia menulis perpustakaan untuk API layanan Yandex.Music pribadi dan hal-hal apa yang ia temui selama pengembangan.
Sekarang Anda tahu bagaimana dan apa aplikasi Windows mereka bekerja, dan karena itu perpustakaan saya.
Ngomong-ngomong, sekarang saya mencoba mendokumentasikan semuanya, ketika mendokumentasikan perpustakaan saya, saya secara otomatis mendokumentasikan API mereka. Sangat ketat, dan saya masih harus punya waktu untuk menemukan perusahaan untuk menjalani praktik teknologi industri.
Terima kasih telah membaca hingga di sini!