‫Instruktur: Jadi sekarang kita tahu apa itu
‫Express, kita hampir siap untuk mulai membangun API kita.
‫Namun sebelum kita
‫melakukannya, saya perlu membahas API di tingkat yang lebih tinggi
‫dengan cepat, dan yang
‫lebih penting, memperkenalkan Anda pada Arsitektur REST
‫yang merupakan arsitektur API yang paling banyak digunakan saat ini.
‫Dengan cara ini, kita akan benar-benar tahu apa yang sedang kita bangun.
‫Jadi sangat penting untuk memahami hal-hal
‫dalam video ini sebelum melanjutkan,
‫sehingga kita benar-benar tahu apa yang kita
‫bangun sepanjang sisa kursus.
‫Pertama-tama, API
‫adalah singkatan dari Application Programming Interface dan pada tingkat
‫yang sangat tinggi, itu
‫pada dasarnya adalah perangkat lunak yang dapat
‫digunakan oleh perangkat lunak lain
‫untuk memungkinkan aplikasi berbicara satu sama lain.
‫Kami sebenarnya telah berbicara tentang
‫API sebelumnya, lebih khusus lagi, API web,
‫di mana kami hanya membangun sebuah aplikasi
‫yang mengirimkan data ke klien setiap kali ada permintaan masuk.
‫Bayangkan kami menjalankan aplikasi kami di server dan
‫kami memiliki klien.
‫Jadi sebenarnya, kita secara efektif memiliki dua perangkat lunak yang
‫berbicara satu sama lain, bukan?
‫Dan ini adalah jenis API yang akan kita bangun dalam kursus ini.
‫Dan saya rasa itu adalah jenis API yang paling banyak digunakan di luar sana.
‫Namun nyatanya, API tidak hanya digunakan untuk mengirim data, dan tidak
‫selalu terkait dengan pengembangan web atau JavaScript.
‫Aplikasi dalam API sebenarnya dapat berarti
‫banyak hal yang berbeda selama perangkat lunak
‫tersebut relatif berdiri sendiri.
‫Ambil
‫contoh, Sistem File Node, atau Modul HTTP.
‫Kita dapat mengatakan bahwa mereka adalah bagian kecil dari
‫perangkat lunak dan
‫kita dapat menggunakannya, kita dapat berinteraksi dengan mereka dengan menggunakan API mereka.
‫Misalnya,
‫ketika kita menggunakan fungsi readfile dari Modul
‫FS, kita sebenarnya menggunakan FS API.
‫Dan itulah mengapa Anda terkadang mendengar istilah node API.
‫Dan itu biasanya hanya mengacu pada modul simpul inti yang
‫dapat berinteraksi dengan kita.
‫Atau ketika kita melakukan manipulasi DOM di
‫browser, kita tidak benar-benar menggunakan bahasa JavaScript itu
‫sendiri, melainkan, DOM API yang diperlihatkan browser kepada kita, sehingga memberi
‫kita akses ke sana.
‫Atau bahkan contoh lain, katakanlah
‫kita membuat kelas dalam bahasa pemrograman apa pun seperti
‫Java dan kemudian menambahkan beberapa metode atau properti
‫publik ke dalamnya.
‫Metode-metode ini kemudian akan menjadi API dari setiap
‫objek yang dibuat dari kelas itu
‫karena kami memberikan perangkat lunak lain
‫kemungkinan untuk berinteraksi dengan perangkat lunak awal kami, objek,
‫dalam kasus ini.
‫Soalnya, API sebenarnya memiliki arti yang lebih luas dari
‫sekadar membangun API web.
‫Baiklah? Bagaimanapun, API web adalah yang
‫paling penting bagi kami dalam konteks catatan.
‫Sekarang mari kita lihat Arsitektur REST untuk
‫membangun API.
‫REST, yang merupakan singkatan dari Representational States Transfer, pada dasarnya
‫adalah cara membangun API web dengan cara yang logis, membuatnya
‫mudah untuk dikonsumsi karena
‫ingat, kita membangun API untuk diri kita sendiri
‫atau untuk dikonsumsi orang lain, oke?
‫Kami ingin membuat proses penggunaan API semulus
‫mungkin bagi pengguna.
‫Sekarang, untuk membangun RESTful
‫API, yang berarti API mengikuti Arsitektur REST,
‫kita hanya perlu mengikuti beberapa prinsip.
‫Pertama, kita perlu memisahkan API kita menjadi sumber daya logis.
‫Sumber daya ini kemudian harus diekspos,
‫yang berarti tersedia
‫menggunakan URL berbasis sumber daya yang terstruktur.
‫Untuk melakukan tindakan yang
‫berbeda pada data seperti membaca atau membuat atau
‫menghapus data, API harus menggunakan metode HTP yang tepat dan bukan URL.
‫Sekarang, data yang sebenarnya kami kirim kembali ke
‫klien atau yang kami terima
‫dari klien biasanya harus menggunakan format data
‫JSON, di mana beberapa standar pemformatan diterapkan padanya.
‫Akhirnya, prinsip penting lainnya dari REST API
‫adalah bahwa mereka harus stateless.
‫Jadi ini adalah gambaran yang sangat luas.
‫Sekarang mari kita mulai berbicara tentang prinsip-prinsip
‫ini satu per satu dimulai dengan sumber daya dan menggunakan
‫Nators API yang akan kita buat dalam kursus
‫ini sebagai contoh di sini.
‫Abstraksi utama informasi di REST adalah sumber daya, dan oleh
‫karena itu semua data yang
‫ingin kami bagikan di API harus dibagi menjadi sumber daya logis.
‫Sekarang, apa sebenarnya sumber daya itu?
‫Nah, dalam konteks REST,
‫itu adalah objek atau representasi dari sesuatu yang
‫memiliki beberapa data yang terkait dengannya.
‫Misalnya,
‫tur, atau pengguna, atau ulasan dalam
‫kasus contoh yang kami ikuti.
‫Jadi pada dasarnya, informasi apa pun yang dapat disebutkan
‫namanya dapat menjadi sumber daya, oke?
‫Itu hanya harus nama, bukan kata kerja.
‫Sekarang, kita
‫perlu mengekspos, yang berarti
‫menyediakan, data menggunakan beberapa URL terstruktur yang
‫dapat dikirimi permintaan oleh klien.
‫Misalnya, sesuatu seperti ini.
‫Seluruh alamat ini disebut URL
‫dan /addNewTour ini disebut Titik Akhir API.
‫API kami akan memiliki banyak titik akhir yang
‫berbeda seperti titik akhir fiksi yang saya miliki di
‫sini, yang masing-masing akan mengirim data yang berbeda kembali ke
‫klien atau juga melakukan tindakan yang berbeda.
‫Sekarang, sebenarnya ada sesuatu yang
‫sangat salah dengan titik akhir ini di sini karena
‫mereka benar-benar tidak mengikuti aturan ketiga yang mengatakan
‫bahwa kita hanya boleh menggunakan metode HTTP untuk melakukan tindakan pada data.
‫Jadi, titik akhir seharusnya hanya berisi sumber daya kami dan
‫bukan tindakan yang dapat dilakukan pada mereka
‫karena mereka akan dengan cepat menjadi mimpi buruk untuk dipertahankan.
‫Bagaimana seharusnya kita menggunakan metode HTTP ini dalam praktik?
‫Nah, mari kita lihat
‫bagaimana seharusnya titik akhir ini dimulai dengan /getTour.
‫Jadi titik akhir /getTour ini adalah untuk mendapatkan data tentang tur.
‫Jadi kita cukup menamai titik akhir /tours dan
‫mengirim data setiap kali permintaan get dibuat
‫ke titik akhir ini.
‫Jadi dengan
‫kata lain, ketika klien menggunakan metode GET
‫HTTP untuk mengakses titik akhir.
‫Dan seperti
‫ini, kami hanya memiliki sumber daya
‫di titik akhir atau di URL dan tidak ada kata
‫kerja karena kata kerjanya sekarang dalam metode HTTP, bukan?
‫Dan omong-omong,
‫itu adalah praktik umum untuk selalu menggunakan nama sumber
‫daya dalam bentuk jamak itulah sebabnya saya memiliki /tours di sini dan bukan /tour.
‫Sekarang, konvensinya adalah ketika memanggil titik akhir
‫itu, kita mendapatkan kembali semua tur yang ada di database, oke?
‫Tetapi jika kita hanya ingin tur dengan satu I. D. katakanlah tujuh, kami
‫menambahkan tujuh setelah garis miring lain atau dalam permintaan pencarian.
‫Atau bisa juga dengan nama wisata bukan I. D. atau pengenal unik lainnya.
‫Detailnya tidak terlalu penting saat ini, oke?
‫Nanti, saya akan menunjukkan
‫kepada Anda betapa mudahnya menerapkan logika semacam ini
‫dengan Express karena di sinilah Express benar-benar bersinar.
‫Metode HTTP atau kata kerja
‫pertama yang dapat kita tanggapi adalah GET dan
‫digunakan untuk melakukan operasi Baca pada data.
‫Perhentian berikutnya, jika klien
‫ingin membuat sumber daya baru di database kami,
‫dalam contoh ini,
‫tur baru, metode POST harus digunakan.
‫Jadi kita belajar sebelumnya bahwa permintaan
‫POST dapat digunakan untuk mengirim data ke
‫server, jadi masuk akal untuk menggunakan POST untuk membuat
‫sumber daya baru, bukan?
‫Sekarang dalam kasus ini, biasanya tidak ada I. D. akan dikirim karena
‫server harus secara otomatis mencari tahu
‫I. D. untuk sumber daya baru.
‫Bagaimanapun, yang benar-benar penting untuk diperhatikan di sini adalah bagaimana nama titik akhir adalah nama yang
‫sama persis seperti sebelumnya.
‫Satu-satunya perbedaan adalah
‫metode HTP yang digunakan untuk permintaan.
‫Jika titik akhir /tours diakses dengan GET, kami
‫mengirim data ke klien.
‫Tetapi jika titik akhir yang sama diakses dengan POST,
‫kami mengharapkan data masuk
‫dengan permintaan, sehingga kami dapat membuat
‫sumber daya baru di sisi server.
‫Jadi itu benar-benar keindahan hanya menggunakan metode HTTP daripada bermain-main
‫dengan kata kerja dalam nama titik akhir.
‫Sekali lagi, itu akan benar-benar menjadi tidak terkendali dengan sangat cepat.
‫Baiklah, selanjutnya, harus ada
‫juga kemampuan untuk memperbarui sumber daya.
‫Dan untuk itu, baik permintaan PUT
‫atau PATCH harus dibuat ke titik
‫akhir.
‫Perbedaan di antara mereka adalah bahwa
‫dengan PUT, klien seharusnya mengirim
‫seluruh objek yang diperbarui, sedangkan
‫dengan PATCH, seharusnya hanya mengirim sebagian dari objek yang
‫telah diubah.
‫Namun keduanya memiliki kemampuan untuk
‫mengirim data ke server.
‫Agak seperti POST, sebenarnya, tetapi dengan maksud yang berbeda.
‫Jadi POST adalah
‫untuk membuat sumber daya baru, sedangkan PUT atau PATCH digunakan
‫untuk memperbarui sumber daya yang ada
‫dan kemudian membuat semua perbedaan.
‫Dan akhirnya, untuk sumber
‫sampah, ada metode HTTP DELETE.
‫Sekali lagi, saya. D. atau pengidentifikasi unik lainnya dari sumber
‫daya yang akan dihapus harus menjadi bagian dari
‫URL.
‫Sekarang, biasanya, untuk benar-benar
‫dapat melakukan
‫permintaan semacam ini, klien harus diautentikasi.
‫Jadi pada dasarnya, masuk ke aplikasi Anda, oke?
‫Tapi itu, tentu saja, topik untuk banyak kemudian.
‫Jadi ini adalah lima metode HTTP
‫yang dapat dan harus kita
‫tanggapi saat membangun RESTful API
‫sehingga klien dapat
‫melakukan empat operasi CRUD dasar.
‫Jadi CRUD adalah singkatan dari Create, Read, Update dan Delete.
‫Dan Anda akan melihat istilah ini
‫sepanjang waktu terkait dengan API dan hal-hal basis data.
‫Dan Anda melihat bahwa metode HTTP
‫ini memetakan dengan cukup baik ke operasi CRUD dasar.
‫Sekarang, mungkin ada tindakan
‫yang bukan CRUD, dan dalam hal ini, kita
‫hanya perlu berkreasi dengan input kita.
‫Misalnya, operasi masuk
‫atau pencarian, ini tidak benar-benar terkait dengan
‫sumber
‫daya tertentu dan juga bukan operasi
‫CRUD, tetapi kita masih dapat membuat titik akhir untuknya.
‫Misalnya, seperti /login atau /search.
‫Tetapi kita akan berbicara lebih banyak tentang kasus-kasus ini nanti dalam praktik.
‫Dan hanya untuk menyelesaikan bagian ini sekarang, ingat
‫bahwa kita memiliki dua nama titik akhir gila lainnya di
‫slide terakhir yang melibatkan
‫dua sumber daya pada saat yang sama, bukan?
‫Dan itu juga tidak masalah sama sekali dengan REST.
‫Jadi, /getToursByUser dapat
‫dengan mudah diterjemahkan ke /users/tours,
‫dalam hal ini, pengguna nomor tiga.
‫Jadi titik akhir khusus ini di sini dapat
‫mengirim data tentang semua tur yang telah
‫dipesan oleh pengguna nomor tiga.
‫Masuk akal?
‫Atau dalam kasus penghapusan, mungkin ada
‫permintaan penghapusan
‫ke titik akhir yang sama atau
‫sangat mirip, meminta tur nomor sembilan dihapus dari
‫pengguna nomor tiga, oke?
‫Jadi sebenarnya ada banyak sekali
‫kemungkinan untuk menggabungkan sumber daya seperti ini.
‫Tapi tentu saja, kita tidak harus mengimplementasikan semua
‫kombinasi ini di API kita.
‫Kami hanya mengimplementasikan apa
‫yang masuk akal dalam kasus aplikasi kami dan
‫klien yang ingin menggunakan API kami.
‫Jadi, inilah cara kami
‫menggunakan metode HTTP untuk membangun URL yang ramah pengguna
‫dan terstruktur dengan baik yang mudah dan logis untuk dikonsumsi oleh klien.
‫Sekarang, tentang data yang sebenarnya diterima klien,
‫atau yang diterima server dari
‫klien, biasanya kami menggunakan Format Data JSON.
‫Jadi mari kita pelajari secara singkat apa itu JSON
‫sebenarnya dan bagaimana memformat respons API kita.
‫JSON adalah format pertukaran data yang sangat
‫ringan yang banyak digunakan
‫oleh API web yang dikodekan dalam bahasa pemrograman apa pun.
‫Jadi itu tidak terkait dengan JavaScript.
‫Dan itu sangat banyak digunakan saat
‫ini karena sangat mudah bagi manusia dan komputer
‫untuk memahami dan menulis JSON.
‫Jadi Anda mungkin sudah memperhatikan bahwa JSON terlihat seperti
‫objek JavaScript biasa, bukan?
‫Dengan semua pasangan nilai kunci ini.
‫Namun, ada beberapa perbedaan, dan yang paling
‫penting adalah bahwa semua kunci
‫harus berupa string.
‫Ini juga sangat khas untuk nilai menjadi string
‫juga tetapi mereka bisa
‫menjadi hal-hal lain seperti angka, nilai benar
‫atau salah, objek lain, atau bahkan array nilai lain.
‫Ini cukup lurus ke depan, sebenarnya.
‫Dan dari contoh ini, Anda dapat melihat
‫seperti apa tampilan JSON yang khas.
‫Katakanlah ini adalah
‫data yang kami miliki di database kami untuk permintaan
‫GET ke URL ini sehingga tur dengan I. D. dari lima.
‫Sekarang, kami dapat mengirimkannya kembali seperti ini ke klien,
‫tetapi kami
‫biasanya melakukan beberapa pemformatan respons sederhana sebelum mengirim.
‫Ada beberapa standar untuk ini dan kita akan menggunakan yang
‫sangat sederhana yang disebut Jsend.
‫Kami cukup membuat objek baru,
‫lalu menambahkan pesan status ke dalamnya untuk memberi tahu klien
‫apakah permintaan itu
‫berhasil, gagal atau salah, dan
‫kemudian kami memasukkan data asli kami
‫ke objek baru yang disebut Data, oke?
‫Dan kami dapat mengembangkan
‫ini lebih jauh lagi tetapi ini adalah cara
‫paling sederhana untuk memformat dengan Jsend.
‫Dan omong-omong, membungkus data
‫menjadi objek tambahan seperti yang kita lakukan
‫di sini
‫disebut Enveloping, dan itu adalah praktik umum untuk
‫mengurangi beberapa masalah keamanan dan masalah lainnya.
‫Selain itu, ada
‫standar lain untuk pemformatan respons yang dapat Anda lihat, seperti Jsend:API
‫atau Protokol JSON Odata.
‫Baiklah, dan akhirnya,
‫RESTful API harus selalu stateless.
‫Jadi, apa sebenarnya yang dimaksud dengan stateless?
‫Nah, dalam RESTful API stateless, semua
‫status ditangani di
‫klien dan bukan di server.
‫Dan status hanya mengacu pada sepotong data dalam aplikasi
‫yang mungkin berubah seiring waktu.
‫Misalnya, apakah pengguna tertentu masuk atau
‫di halaman dengan daftar dengan beberapa
‫halaman,
‫apa halaman saat ini.
‫Sekarang fakta bahwa status harus ditangani pada klien
‫berarti bahwa setiap
‫permintaan harus berisi semua informasi
‫yang diperlukan untuk memproses permintaan tertentu di server, oke?
‫Apakah itu masuk akal?
‫Jadi, server seharusnya tidak perlu
‫mengingat
‫permintaan sebelumnya untuk memproses permintaan saat ini.
‫Mari kita ambil daftar dengan beberapa halaman sebagai contoh.
‫Dan katakanlah berulang-ulang di
‫halaman lima dan ingin maju ke halaman enam.
‫Jadi kita bisa memiliki titik akhir sederhana yang disebut
‫/tours/nextPage dan mengirimkan permintaan ke sana, bukan?
‫Tetapi server kemudian harus mencari tahu apa halaman
‫saat ini dan berdasarkan itu mengirim
‫halaman berikutnya ke klien.
‫Dengan kata lain, server harus
‫mengingat permintaan sebelumnya.
‫Itu harus
‫menangani sisi server negara bagian dan itulah yang
‫ingin kita hindari di RESTful API, oke?
‫Sebagai gantinya, dalam kasus ini, kita
‫harus membuat titik akhir /tours/page dan menempelkan
‫nomor enam
‫ke sana untuk meminta nomor halaman enam.
‫Dengan cara ini, kami kemudian akan
‫menyatakan pada klien karena pada klien, kami sudah
‫tahu bahwa kami berada di halaman lima dan jadi
‫yang harus kami
‫lakukan hanyalah menambahkan satu dan kemudian meminta nomor halaman enam.
‫Jadi server tidak perlu mengingat apa
‫pun dalam kasus ini.
‫Yang harus dilakukan adalah mengirim
‫kembali data untuk halaman nomor enam seperti yang kami minta.
‫Dan omong-omong, statelessness dan statefulness,
‫yang merupakan kebalikannya, adalah konsep yang
‫sangat penting dalam ilmu komputer dan desain
‫aplikasi secara umum.
‫Jadi, ada baiknya untuk benar-benar memahami apa itu
‫API stateless dan cara kerjanya.
‫Bagaimanapun, ini adalah kuliah besar, tetapi juga
‫salah satu yang paling penting.
‫Saya tidak bisa cukup menekankan itu dan saya benar-benar
‫berpikir bahwa Anda dapat melihatnya, bukan?
‫Bagaimanapun, sekarang mari kita kembali ke kode kita.