Modul pertama berakhir dengan Anda membuat permintaan HTTP, mengirimnya, dan mendapatkan respons.

Kami akan melakukan ini berkali-kali di masa depan. Kami akan mengirimkan permintaan ke server pihak ketiga. Kami akan membuat aplikasi yang dengan sendirinya menerima permintaan tersebut dan membalasnya. Kami akan membuat logika kompleks untuk memproses permintaan.

Oleh karena itu, akan baik untuk mempelajari secara menyeluruh segala sesuatu yang berkaitan dengan permintaan ini, untuk menganalisisnya secara rinci. Sehingga Anda tidak bisa hanya menyalin permintaan di suatu tempat dan mengulanginya, tetapi benar-benar mencari tahu cara kerjanya.

Inilah yang akan kita lakukan di modul kedua. Ayo pergi!

Mari kita mulai dengan teori.


Mempelajari REST API

Dasar-dasar REST API

Jika Anda mengerjakan pekerjaan rumah Anda di modul pertama dan mempelajari dokumentasinya, Anda seharusnya memperhatikan akronim API. Sebenarnya, dokumentasi API adalah hal pertama yang harus dipelajari pengembang jika mereka ingin memahami interaksi dengan beberapa layanan atau aplikasi di jaringan.

API - Antarmuka Pemrograman Aplikasi. Ini adalah deskripsi cara di mana klien dan server dapat berkomunikasi satu sama lain. Kami membuka dokumentasi API dan belajar dari sana cara mendapatkan data yang diperlukan dari server.

Kami selalu ingin interaksi ini sederhana dan dapat dimengerti. Ini menyederhanakan tugas untuk kedua pengembang (tidak perlu menemukan kembali roda saat merancang layanan baru) dan pengguna (layanan jauh lebih mudah dipelajari jika bekerja dengan prinsip yang sama seperti layanan yang sudah dikenal sebelumnya). Dan di sini perlu diingat istilah baru - REST.

REST -singkatan dari Representational State Transfer . Ini mungkin tidak terdengar sangat jelas, tetapi sederhananya, REST adalah gaya interaksi (pertukaran informasi) antara klien dan server.

Ini bukan seperangkat aturan dan persyaratan yang kaku. REST tidak memaksa penggunaan bahasa pemrograman tertentu, juga tidak mengikat tangan dengan pedoman yang ketat. REST disebut gaya arsitektur dan mendefinisikan 6 prinsip yang harus dipatuhi oleh arsitektur sistem.

Oleh karena itu, API yang dikembangkan dengan mempertimbangkan prinsip-prinsip REST disebut REST API , dan aplikasi itu sendiri disebut RESTful

Kami akan membuat aplikasi RESTful seperti itu, jadi ada baiknya mendiskusikan prinsip-prinsip yang akan mereka patuhi segera.

  1. Model Server-Klien. Prinsip mendefinisikan pemisahan klien dan server, diferensiasi kebutuhan mereka. Klien tidak perlu khawatir tentang bagaimana data disimpan, yang utama adalah bahwa itu dikeluarkan berdasarkan permintaan. Pada gilirannya, server tidak peduli apa yang akan dilakukan klien dengan data ini, bagaimana memproses dan menampilkannya lebih lanjut. Ini memungkinkan mereka untuk berkembang secara independen satu sama lain, dan meningkatkan skalabilitas sistem.
  2. keadaan tanpa kewarganegaraan. Prinsip ini berarti bahwa server tidak boleh "memikirkan" respons berdasarkan pengalaman sebelumnya dengan klien ini. Setiap permintaan dibuat sedemikian rupa sehingga berisi semua informasi yang diperlukan untuk pemrosesannya, terlepas dari permintaan sebelumnya.
  3. Caching. Untuk meminimalkan data yang dikirimkan, ada mekanisme caching. Misalnya, jika logo ditampilkan di beberapa halaman, maka tidak masuk akal untuk memintanya dari server setiap saat. Itu tidak sering berubah, itu akan cukup untuk mendapatkannya sekali dan menyimpannya di komputer klien, di cache. Tetapi jika kita perlu mendapatkan informasi tentang kecepatan mobil saat ini, maka cache tidak akan membantu dengan cara apa pun. Prinsip ini menentukan bahwa data yang dikirimkan oleh server harus ditetapkan sebagai cacheable atau tidak.
  4. Antarmuka seragam. Prinsipnya mendefinisikan format tunggal interaksi client-server. Struktur semua permintaan harus sama. Data harus dikirim dalam bentuk yang sama, terlepas dari siapa yang memintanya.
  5. Sistem Berlapis. Klien dan server tidak harus berkomunikasi secara langsung. Transmisi data dapat melalui beberapa node perantara. Dalam hal ini, sistem dirancang sedemikian rupa sehingga baik klien maupun server tidak tahu apakah mereka berinteraksi dengan aplikasi akhir atau simpul perantara. Ini memungkinkan Anda untuk menyeimbangkan beban di server, meningkatkan skalabilitas.
  6. Kode sesuai permintaan (opsional) . Satu-satunya prinsip yang tidak wajib. Menurutnya, klien dapat memperluas fungsinya dengan mengunduh kode yang dapat dieksekusi dari server (misalnya, skrip). Dalam hal ini, kode harus dieksekusi hanya sesuai permintaan.

Tidak terlalu banyak teori?

Mari kita mempraktekkannya.

Membuat permintaan API

Mari buka AppMaster , buat permintaan API dengan menggunakannya, dan dapatkan pemahaman yang lebih baik tentang cara kerja permintaan ini.


Permintaan API dibuat di bagian "Logika bisnis", di tab "Permintaan API Eksternal".

Saatnya klik "+ Permintaan API Baru".


Nama dan deskripsi dapat diatur untuk apa saja, hanya untuk penggunaan pribadi kami.

Mari kita berurusan dengan data yang benar-benar penting.

Persyaratan minimum untuk membuat permintaan adalah menentukan Metode dan alamatnya (URL). Mari kita mulai dengan yang terakhir.


URL - Uniform Resource Locator. Alamat yang diberikan ke sumber daya tertentu di Internet. Versi paling akrab dari sumber daya semacam itu adalah halaman HTML - kami memasukkan URL-nya di bilah alamat browser dan membuka situs yang diinginkan. Pada saat yang sama, sumber daya itu sendiri dapat berupa apa saja, gambar, video, kumpulan data. Hal utama adalah bahwa sumber daya ini memiliki penunjuk khusus - URL tempat Anda dapat mengirim permintaan untuk mendapatkan sumber daya ini.

Mengacu pada data di alamatnya, kami juga menunjukkan metode (Anda juga dapat mengatakan jenisnya) permintaan, yaitu, kami menunjukkan apa yang sebenarnya perlu dilakukan dengan data ini.

Ketika kami mengirim permintaan untuk tugas modul pertama, kami menerima data. Ini adalah metode GET. Metode ini adalah metode yang paling jelas dan juga satu-satunya yang diperlukan. Oleh karena itu, meskipun kami tidak menentukannya secara eksplisit, secara default masih diasumsikan bahwa ini adalah GET.

Mari kita lihat metode lain apa yang ada.


Standar HTTP sendiri tidak membatasi jumlah metode yang dapat digunakan. Pada saat yang sama, hanya beberapa metode paling standar yang masih digunakan untuk menjaga kompatibilitas. Ada 5 metode berbeda yang dapat digunakan dalam permintaan API AppMaster.

  • DAPATKAN . Itu sudah ditangani. Metode meminta penyediaan sumber daya, dan menerima data.
  • POSTING Untuk mengambil data dari suatu tempat, Anda harus terlebih dahulu menempatkan data ini di sana. Metode POST melakukan hal itu. Mengirim data ke server, membuat sumber daya.
  • PUT . Mirip dengan metode POST, tetapi tugasnya adalah memperbarui data. Itu tidak membuat data baru, tetapi menggantikan data yang ada, memperbaruinya.
  • HAPUS . Seperti namanya, itu menghapus data.
  • PATCH . Metode ini mirip dengan PUT, tetapi digunakan untuk memperbarui sebagian data, daripada menggantinya seluruhnya. Misalnya, menggunakan metode PATCH, Anda dapat mengubah judul artikel, atau mengubah nilai beberapa parameter.

Penting untuk mempertimbangkan fakta bahwa server tidak diharuskan untuk melakukan persis apa yang ditentukan dalam metode ini sama sekali. Kami dapat mengirim alamat beberapa halaman dengan metode DELETE, tetapi ini tidak berarti bahwa server benar-benar akan menghapusnya. Tapi, murni secara teoritis, dia bisa melakukan ini dengan perintah GET. Atau jangan mengubah apa pun, tetapi pada saat yang sama mengirim data sebagai tanggapan terhadap POST. Hanya karena pengembang mengonfigurasinya seperti itu.

Di sinilah REST berperan, yang mengatakan bahwa inilah saatnya untuk menyetujui kepatuhan terhadap perintah, hentikan kekacauan dan lakukan persis apa yang ditunjukkan dalam metode ini. Paling tidak, ini harus menjadi tugas utama (walaupun belum tentu satu-satunya). Misalnya, saat mentransfer konten artikel menggunakan metode GET, Anda dapat sekaligus meningkatkan penghitung jumlah penayangannya sebanyak 1.

Jadi, kami menemukan di mana data itu berada dan apa yang bisa dilakukan dengannya. Mari kita melangkah lebih jauh, mari kita lihat komponen lain apa yang dapat dimiliki permintaan.


Parameter URL. Ada situasi di mana kita hanya mengetahui sebagian dari URL. Contohnya adalah artikel di situs web Appmaster.io. Alamat awal untuk semua artikel adalah sama - https://appmaster.io/en/blog/. Tetapi kemudian setiap artikel memiliki judulnya sendiri dan, karenanya, bagian individualnya sendiri untuk indikasi yang tepat dari artikel khusus ini.

Dalam situasi seperti itu, Params URL digunakan. Kami segera meresepkan bagian umum, dan membiarkan sisanya diputuskan dalam proses. Akibatnya, URL ditulis dalam bentuk https://appmaster.io/ru/blog/:id/

Bagian yang diketahui ditulis apa adanya, dan bagian variabel ditempatkan setelah tanda “:”. Nama bagian variabel ini (sudah tanpa “:”) ditambahkan ke daftar parameter. Dalam hal ini, mungkin ada beberapa bagian variabel, dan lokasinya ada di mana saja di URL.


Parameter Kueri . Ingat ketika kami mengirim permintaan ke boreapi.com di modul pertama? Dan selain alamat, data tambahan ditentukan. Itu adalah Param Kueri.

Mereka ditulis setelah URL dan dipisahkan oleh tanda “?” tanda. Nama parameter, tanda "=" dan nilai parameter itu sendiri ditunjukkan. Jika beberapa parameter digunakan sekaligus, mereka dipisahkan oleh tanda “&”.

Namun, saat menentukan parameter di AppMaster, Anda tidak perlu memikirkan aturan permintaan. Semuanya akan diformat dengan benar secara otomatis. Anda hanya perlu menentukan nama parameter itu sendiri dan menambahkannya ke daftar.

Param Kueri digunakan jika sumber datanya sama, tetapi datanya sendiri bisa berbeda. Misalnya, Boredapi berisi daftar besar hal yang harus dilakukan. Tetapi kami hanya tertarik pada yang ditujukan untuk satu orang, dan itulah yang kami tunjukkan dalam parameter permintaan.

Pilihan lainnya adalah kunci akses. Anda mungkin telah menggunakan opsi ini di modul 1 saat merujuk ke Alphavantage. Data dapat diperoleh hanya setelah pendaftaran dan pengiriman kunci pribadi dalam parameter permintaan.

Perhatikan halaman yang Anda kunjungi di Internet, Anda mungkin juga akan menemukan berbagai parameter di dalamnya. Misalnya, buka halaman cuaca Ventusky.com, dalam parameter kueri nilai geografis lintang dan bujur dikirim.

Header . Minta header. Biasanya header berisi informasi layanan tentang permintaan (meta-informasi). Header memungkinkan server untuk mendapatkan informasi lebih lanjut tentang klien yang meminta data. Header dapat berisi informasi tentang browser mana yang digunakan, pengkodean apa yang diharapkan dari respons, dalam bahasa apa, waktu permintaan yang tepat, dan banyak lagi. Dalam hal akses ke data yang dilindungi, header mungkin berisi kunci otorisasi.

Dalam kebanyakan kasus, header bersifat opsional. Bahkan di modul pertama, kami sudah membuat permintaan di mana kami tidak menentukan header apa pun (meskipun ini tidak berarti bahwa permintaan itu benar-benar dikirim tanpa header).

Tubuh . Badan permintaan. Permintaan GET biasanya dilakukan tanpa itu, tetapi jika kita ingin mengirim beberapa data ke server, mengirim permintaan POST atau PUT, maka data ini ditempatkan di badan permintaan. Pada saat yang sama, Anda dapat menempatkan data dengan kompleksitas apa pun di badan permintaan, misalnya, mengirim file video, dan tidak terbatas pada beberapa nomor atau string teks.

Respon yang datang dari server bekerja hampir sesuai dengan skema yang sama. Itu, untuk alasan yang jelas, tidak memiliki parameter permintaan, tetapi Header dan Body disertakan dalam respons (walaupun mungkin kosong).

Perbedaan penting adalah status respons.

Kode status . Muncul di baris pertama dari respons server. Statusnya adalah angka tiga digit (kode itu sendiri), diikuti dengan frasa yang menjelaskannya.

Dengan kode status Anda dapat mengetahui tentang hasil permintaan dan memahami tindakan apa yang harus diambil selanjutnya.

Semua kemungkinan kode status dibagi menjadi 5 kelas. Digit pertama kode menentukan milik kelas tertentu. Mari kita hancurkan mereka.

1xx — kode informasi. Laporkan kemajuan permintaan. Dalam praktik nyata, mereka jarang digunakan.

2xx — kode sukses. Mereka melaporkan bahwa semuanya beres dan permintaan berhasil diselesaikan. Menanggapi permintaan GET, kami biasanya mengharapkan untuk menerima kode 200 (OK). Permintaan PUT yang berhasil mengirimkan kode 201 (Dibuat).

3xx — pengalihan. Tunjukkan bahwa permintaan harus dikirim ke alamat yang berbeda. Contohnya adalah kode 301 (Dipindahkan Secara Permanen), menunjukkan bahwa data yang diperlukan sekarang berada di alamat baru (alamat baru itu sendiri diteruskan di header Lokasi).

4xx — kode kesalahan klien. Yang paling terkenal di antara mereka - 404 (Tidak Ditemukan), melaporkan bahwa tidak ada data yang diperlukan di alamat yang ditentukan. Kasus umum lainnya: 400 (Permintaan Buruk, kesalahan sintaks dalam permintaan), 401 (Tidak sah, diperlukan otentikasi untuk akses), 403 (Terlarang, akses ditolak).

5xx — kode kesalahan server. Laporkan kesalahan di sisi server. Sebagai contoh: 500 (Kesalahan Server Internal, kesalahan yang tidak dapat dipahami yang tidak dapat dikaitkan dengan kode yang diketahui), 503 (Layanan Tidak Tersedia, server untuk sementara tidak dapat memproses permintaan karena alasan teknis)

Pada titik ini, kita dapat berasumsi bahwa kita telah membahas informasi dasar untuk memahami REST API dan struktur permintaan dan tanggapan HTTP. Masih mengklarifikasi hanya satu poin - tipe data. Jika Anda sudah mencoba membuat permintaan API di AppMaster, Anda mungkin memperhatikan bahwa semua data (dalam parameter, di header, di badan) meminta Anda untuk menentukan tidak hanya nama, tetapi juga tipe data.


Biasanya cukup jelas bagi manusia bagaimana bekerja dengan data, karena ada konteks tertentu. Misalkan kita tahu bahwa 2 + 2 = 4. Kita menebak bahwa ini adalah angka dan hasil penjumlahan akan menjadi angka lain.

Tapi itu mungkin bukan angka, tetapi data tekstual. Kemudian hasil dari penambahan mereka bisa menjadi rangkaian string dan 2 + 2 akan berubah menjadi "22". Di sini, agar komputer tidak perlu memikirkan apa pun, ada indikasi yang tepat tentang tipe data. Dan pada saat yang sama, tugas-tugas lain sedang diselesaikan. Misalnya, perlindungan diberikan terhadap memasukkan data yang salah; awalnya, tidak ada kesempatan untuk mendaftarkan alamat email di bidang yang dimaksudkan untuk memasukkan nomor nomor telepon.

Ada cukup banyak tipe data yang berbeda, sekarang kita akan mempertimbangkan yang paling dasar, dan dalam modul selanjutnya dari kursus kita akan berkenalan dengan sisanya.

String — Tipe data string, teks biasa tanpa pemformatan khusus.

Integer — Tipe data integer. Dapat digunakan untuk penghitung atau perhitungan di mana angka pecahan tidak diperlukan

Float — Nomor titik mengambang. Ini digunakan di mana peningkatan presisi diperlukan dan nilai integer tidak cukup.

Sebuah pertanyaan logis mungkin muncul di sini. Dan mengapa tidak selalu menggunakan Float, mengapa kita membutuhkan Integer? Tetapi akurasi yang lebih besar membutuhkan lebih banyak sumber daya. Untuk beberapa perhitungan kecil ini mungkin sama sekali tidak terlihat, tetapi dalam kasus data dalam jumlah besar, menggunakan tipe data yang wajar dapat secara signifikan mengurangi kebutuhan daya komputasi dan ruang disk.

Boolean — tipe data boolean. Tipe data paling sederhana. Dibutuhkan salah satu dari dua nilai, yang ditulis sebagai Benar atau Salah. Anda sering dapat melihat penunjukan dalam bentuk 1 (benar) dan 0 (salah).


Pekerjaan rumah

Ulangi permintaan dari pekerjaan rumah ke modul pertama dengan membuatnya di AppMaster di bagian Permintaan API Eksternal.

  1. Buat permintaan ke BoredAPI. Tentukan setidaknya 5 parameter berbeda dari dokumentasi. Kirim beberapa permintaan berbeda, yang hanya menentukan parameter yang diperlukan.
  2. Buat permintaan ke Alphavantage. Gunakan parameter untuk mendapatkan nilai tukar mata uang yang berbeda dalam kaitannya satu sama lain.