Pertukaran data di berbagai platform lebih penting dari sebelumnya di era integrasi. Pertimbangkan toko online tanpa integrasi. Situs web Anda harus mengembangkan sistem untuk mengelola akun pengguna, langganan email, pemrosesan pembayaran , pengiriman, dan tugas lain selain mengelola daftar produk. Akan lebih efektif untuk mengalihdayakan tugas-tugas ini ke penyedia lain karena ini bukan opsi yang dapat diskalakan.
Antarmuka pemrograman aplikasi , atau API web, adalah apa yang digunakan program perangkat lunak untuk berkomunikasi satu sama lain. API menawarkan protokol yang konsisten untuk bertukar data antara dua program. Dengan bantuan web API, toko online Anda dapat berkomunikasi dengan perangkat lunak pengiriman, aplikasi klien, aplikasi pembayaran, dan koneksi lain yang diperlukan.
Ada berbagai cara untuk membuat API; namun, jika Anda ingin menambahkan koneksi perangkat lunak ke layanan Anda, ada satu teknik unik yang harus Anda ketahui: layanan web REST API. Pada artikel ini, kita akan membahas contoh REST API, apa itu REST API, cara kerja REST API, kegunaan REST API, riwayat, elemennya, dan lainnya.
Apa sebenarnya REST API itu?
Transfer status representasional atau layanan web REST API adalah praktik paling standar untuk menautkan komponen dalam kerangka kerja layanan mikro karena mereka menawarkan cara portabel dan serbaguna untuk menggabungkan aplikasi. REST adalah desain API populer yang kami gunakan untuk berinteraksi dengan pemangku kepentingan internal dan eksternal dengan cara yang terstandarisasi dan dapat diprediksi.
Pengguna aplikasi web sering menggunakan layanan web REST API untuk berkomunikasi satu sama lain. Misalnya, memperoleh dan meninjau detail akun dalam program media sosial . Peramban REST API dapat dilihat sebagai sintaks web. Pelanggan online menggunakan API web untuk menyediakan dan mengelola akses ke operasi digital seiring dengan meningkatnya penggunaan cloud.
Merancang API web yang memungkinkan pelanggan untuk terhubung, mengelola, dan terlibat dengan layanan web digital secara dinamis dalam konteks yang tersebar adalah keputusan yang masuk akal. Situs web seperti Google, eBay, Facebook, Amazon, dan Twitter menggunakan layanan web RESTful. Aplikasi klien sekarang dapat menggunakan REST untuk mengakses layanan web ini.
Teknologi REST lebih disukai daripada teknologi terkait lainnya. Ini karena layanan web REST mengkonsumsi lebih sedikit bandwidth, yang membuatnya ideal untuk aktivitas online yang efisien. Layanan web RESTful juga dapat dikembangkan menggunakan bahasa pemrograman seperti JavaScript atau Python.
Bagaimana cara kerja REST API?
Untuk mengetahui cara kerja REST API , kita harus mendefinisikan beberapa istilah kunci:
Klien
Pengguna API disebut sebagai klien. Klien mengirimkan kueri ke API web untuk mendapatkan data atau menerapkan modifikasi pada program. Browser internet Anda adalah klien; itu berkomunikasi dengan berbagai API web untuk mendapatkan konten halaman. Komputer Anda menerima informasi yang diperlukan, yang kemudian ditampilkan di layar.
Berikut ini adalah metode HTTP yang paling populer:
- Gunakan permintaan GET untuk mengembalikan data yang diminta atau sumber daya yang diminta.
- Gunakan permintaan POST untuk membuat sumber daya baru
- Gunakan instruksi PUT untuk membuat perubahan atau terus memperbarui sumber daya yang ada
- Gunakan perintah DELETE untuk menyingkirkan sumber daya.
Misalnya, permintaan HTTP ke API Youtube dapat berupa sumber permintaan GET untuk video atau pos tertentu atau permintaan POST untuk memublikasikan foto baru. Anda dapat menggunakan metode permintaan POST untuk menerbitkan posting baru. Sejalan dengan itu, platform layanan web pelanggan yang terintegrasi dengan implementasi penjawab otomatis dapat menggunakan instruksi PUT untuk memperbarui atau menghilangkan halo kustom.
Dapatkan Permintaan
- Cache permintaan GET dimungkinkan. Riwayat browser mencakup permintaan GET.
- Menandai permintaan GET dimungkinkan.
- Jangan pernah menggunakan permintaan GET saat bekerja dengan materi penting.
- Ada batasan panjang pada permintaan GET.
- Hanya kueri data yang dibuat melalui permintaan GET
Metode POSTING
Permintaan POST adalah metode posting untuk mengirim informasi ke server untuk menambah atau memperbarui sumber daya. Badan permintaan permintaan HTTP berisi data yang dipublikasikan ke sisi server:
- POST meminta metode posting tidak pernah masuk ke cache.
- Permintaan POST tidak disimpan dalam riwayat browser.
- Permintaan POST tidak dapat di-bookmark
Badan Respons
Badan respons adalah salah satu elemen penting dari RESTful API. Data yang diminta disertakan dalam badan tanggapan. Badan respons dapat mencakup data yang berkaitan dengan port logika keluaran dan keluaran.
Sumber
Data apa pun yang dapat diberikan oleh API web kepada pengguna adalah sumber daya. Misalnya, individu, halaman, gambar, atau komentar semuanya dapat dianggap sebagai sumber daya di Facebook API. Pengidentifikasi sumber daya adalah istilah khusus yang diberikan untuk setiap sumber daya.
Server Web
Program yang menerima badan permintaan pelanggan menggunakan server web, yang menampung sumber daya yang diminta konsumen. Server dapat berkomunikasi dengan klien melalui API tanpa menawarkan akses langsung kepada pelanggan ke informasi yang disimpan dalam basis datanya . Saat pengguna mengakses layanan web RESTful untuk mengirimkan badan permintaan, server mengirimkan penggambaran yang dinormalisasi dari status sumber daya ke browser.
Ini menandakan bahwa server entah bagaimana tidak mengirimkan sumber daya yang tepat ke klien melainkan mencerminkan kondisinya, yaitu, situasi sumber daya pada stempel waktu tertentu. Untuk membantu pemahaman, tanggapan dikembalikan dalam format yang ringan.
JSON (JavaScript Object Notation) banyak digunakan karena dapat dibaca oleh orang dan mesin dan unggul dalam membantu mempromosikan aksesibilitas web. JSON terutama digunakan untuk mengirim badan permintaan dalam aplikasi web dan aplikasi klien. Ini adalah bentuk yang kompatibel dengan berbagai pengkodean. Format data API selain JSON melibatkan XML , YAML, CSV, HTML, dan teks biasa. Pengguna API dapat memilih format data apa pun yang mereka inginkan dengan menggunakan jenis media khusus.
Sejarah REST API
Banyak programmer harus bekerja dengan SOAP sebelum REST untuk menggabungkan API. Membangun, memanfaatkan, dan men-debug SOAP adalah tugas yang sangat sulit. Untungnya, REST dikembangkan oleh tim programmer di bawah arahan Roy Fielding, selamanya mengubah lingkungan API.
Berikut adalah kronologi pengembangan REST API dari waktu ke waktu:
Sebelum istirahat
Pemrogram secara manual menulis file XML yang berisi Panggilan Prosedur Jarak Jauh (RPC) di dalam konten untuk menghubungkan API web menggunakan SOAP. Setelah itu, desainer akan POST paket SOAP mereka ke titik akhir yang ditentukan.
Pada tahun 2000
Sebuah tim pemrogram yang dipimpin oleh Roy Fielding memilih untuk mengembangkan kerangka kerja yang memungkinkan server mana pun untuk berkomunikasi dengan server lain. Dia menetapkan batasan untuk REST API. Karena pedoman ini bersifat universal, mengembangkan perangkat lunak menjadi lebih mudah.
Pada tahun 2002
eBay mengembangkan RESTful API pada tahun 2002, membuka pasarnya ke situs web apa pun yang mungkin mendapat manfaat darinya. Karena itu, raksasa e-commerce lain, Amazon, menjadi tertarik padanya dan, pada tahun 2002, merilis RESTful API-nya.
Pada tahun 2004–2006
Layanan web RESTful Flickr dirilis pada tahun 2004, memungkinkan penulis untuk dengan cepat menambahkan foto ke situs web dan pos media sosial mereka. Ketika Twitter dan Facebook melihat sejumlah besar pemrogram memindai situs web dan membuat API "Frankenstein", mereka berdua mengekspos API mereka sekitar dua tahun kemudian.
Pada tahun 2006-Sekarang
Layanan web RESTful sekarang diterima secara luas oleh programmer, yang menggunakan layanan web RESTful ini untuk meningkatkan kinerja aplikasi dan situs mereka. AppMaster memfasilitasi kerja sama dan mempermudah pembuatan API, memungkinkan Anda melakukannya dengan lebih cepat.
Untuk apa REST API digunakan?
Salah satu manfaat utama dari layanan web RESTful adalah ia menawarkan banyak fleksibilitas, memungkinkan Anda untuk menggunakan API RESTful ini secara lebih efektif. Di bawah ini adalah beberapa contoh REST API tentang kegunaan REST API.
Aplikasi berbasis cloud
Karena panggilannya yang tidak memiliki kewarganegaraan, REST API menguntungkan dalam aplikasi cloud. Modul stateless dapat dengan mudah menginstal ulang dan berkembang untuk memenuhi persyaratan kapasitas jika terjadi kesalahan. Program perangkat lunak yang menggabungkan komponen berbasis lokal dan internet adalah aplikasi cloud. Paradigma ini menggunakan server jauh yang diakses oleh browser web dan layanan web internet berkelanjutan untuk mengeksekusi instruksi.
Lokasi tradisional host aplikasi cloud adalah sistem komputer jarak jauh yang dijalankan oleh operator jaringan komputasi awan pihak ketiga. Mail, berbagi dan penyimpanan dokumen, input pesanan, kontrol inventaris, Microsoft Word, manajemen hubungan pelanggan ( CRM ), pengumpulan informasi, dan keuangan dan akuntansi adalah contoh pekerjaan yang dilakukan dengan aplikasi berbasis cloud.
Antarmuka pemrograman Aplikasi REST ( API ) dapat digunakan untuk menghubungkan sumber informasi eksternal dan sumber daya penyimpanan. Pemrogram dapat membuat aplikasi cloud lebih kecil menggunakan REST API untuk mentransfer data ke program lain untuk menangani atau menganalisis perhitungan dan mengembalikan temuan ke program perangkat lunak. API yang diuji menerapkan keseragaman aktif, yang dapat mempercepat produksi dan menghasilkan hasil yang nyata.
Contoh utama dari aplikasi cloud adalah Google Docs atau Office 365. Yang Anda butuhkan untuk Google Docs atau Office 365 adalah komputer yang dapat menjalankan mesin pencari dan layanan web internet. Jaringan komputer menyediakan antarmuka pengguna dan operasi, termasuk penyimpanan informasi. Banyak aplikasi cloud yang berbeda dapat di-host oleh perusahaan Anda menggunakan host aplikasi cloud.
Layanan awan
Karena Anda perlu mengelola bagaimana URL diproses untuk terhubung ke sumber daya melalui API, REST API juga berguna untuk layanan web cloud. Arsitektur layanan web RESTful kemungkinan sekarang akan menjadi standar di masa depan karena aplikasi cloud. Pemrogram menggunakan layanan web RESTful untuk terhubung ke layanan cloud menggunakan internet. Pengembang membuat kode yang menggunakan API penyedia internet, memberikan input dan variabel yang diperlukan, lalu memeriksa jawabannya untuk memastikan tindakan berfungsi seperti yang diharapkan.
Pengguna akhir dapat mengakses aplikasi klien atau layanan web yang ditawarkan oleh layanan web cloud, seperti infrastruktur komputasi, sistem penyimpanan, atau sistem pelacakan, menggunakan layanan cloud seperti layanan web RESTful. API menguraikan kemampuan dan operasi aplikasi serta spesifikasi yang diperlukan untuk menjalankannya. Untuk menjaga privasi dan keamanan klien, API sering kali bergantung pada interoperabilitas dan mekanisme izin REST atau Simple Object Access Protocol (SOAP) seperti OAuth 2.0.
Berbagai layanan web disebut sebagai "layanan cloud" dan tersedia untuk bisnis dan konsumen secara online berdasarkan permintaan. Layanan web ini dibuat untuk menawarkan akses cepat dan murah ke alat dan aplikasi tanpa memerlukan perangkat keras atau infrastruktur. Sebagian besar staf menggunakan layanan web cloud untuk semuanya, mulai dari email hingga kolaborasi dokumen.
Penggunaan web
API web ini dapat diperoleh dari proyek web pengguna, aplikasi iPhone , perangkat IoT, atau Windows Mobile karena REST tidak bergantung pada fungsionalitas sisi klien. Anda dapat membuat arsitektur untuk bisnis Anda tanpa dibatasi oleh kerangka kerja sisi klien tertentu.
Contoh REST API
Mari kita bahas contoh REST API. Klik tautan di bawah untuk meminta Open Trivia Database penyelidikan intelijen sewenang-wenang: Layanan web RESTful seperti itu digunakan untuk menyediakan API web publik. Komputer Anda akan menampilkan pertanyaan kuis tunggal dan tanggapannya dalam format JSON.
Menggunakan browser HTTP apa pun, seperti url, Anda dapat mengeluarkan kueri berikut dan menerima respons di badan respons: https://opentdb.com/api.php?amount=1&category=18
Badan Respon dari file XML layanan web akan berisi semua informasi karyawan.
Semua dialek pemrograman dan alat pengembang yang banyak digunakan memiliki pustaka klien HTTP, seperti mengambil dalam JavaScript, Node.js, dan Deno dan file get content() dalam PHP. Jawaban JSON dapat dibaca dan digunakan karena dapat dibaca oleh mesin sebelum ditampilkan dalam HTML atau gaya lain.
API Istirahat dan REST
Seiring waktu, banyak metode transmisi data telah berkembang. Anda mungkin telah menemukan pilihan seperti CORBA, SOAP, atau XML-RPC. Pedoman pesan ketat yang paling berkembang. Roy Fielding pertama kali menguraikan REST pada tahun 2000, yang jauh lebih lugas daripada yang lain.
Ini adalah kumpulan saran dan batasan untuk layanan web RESTful daripada norma. Ini terdiri dari batasan arsitektur berikut:
Partisi Client-Server
Klien dan server web hanya dapat berkomunikasi dalam satu arah di bawah arsitektur REST: klien meminta pengontrol domain, dan pengontrol atau server merespons permintaan tersebut. Server web tidak dapat mengirimkan permintaan, dan pelanggan tidak dapat bereaksi; konsumen memulai semua koneksi.
Layanan web RESTful membuat pelanggan dan server terisolasi dengan memudahkan interaksi di antara mereka. Komputer klien dapat berkembang tanpa takut memengaruhi hosting lain, dan materi server dapat diubah tanpa tanpa disadari memengaruhi pelanggan.
Antarmuka seragam
Menurut strategi ini, semua pertanyaan dan reaksi harus mematuhi prosedur proweb standar atau gaya pesan mereka. Aplikasi dan server dikembangkan dalam berbagai bahasa pemrograman yang berkinerja buruk satu sama lain dengan mediator. Antarmuka yang seragam adalah dialek yang dapat digunakan pelanggan mana pun untuk berinteraksi dengan API REST apa pun.
Menerjemahkan permintaan dan reaksi antara aplikasi dengan interaksi yang dinormalisasi hanya akan mungkin. Perbedaan kecil akan mengacaukan dan kehilangan informasi, dan solusi harus meningkatkan prosedur permintaan mereka ketika API web memodifikasi milik mereka. Antarmuka yang konsisten menghilangkan prospek ini.
DAPATKAN AKSES KE https://www.googleapis.com/youtube/v3/channels?part=contentDetails
Seperti semua aplikasi REST Client, proposal ini mencakup dua bagian data. Teknik HTTP adalah GET. Ini menjelaskan tindakan yang ingin dilakukan klien pada sumber daya. Seorang pengguna dapat membuat empat metode HTTP dasar:
HTTP, atau Hyper-Text Transfer Protocol, adalah bahasa universal untuk sebagian besar REST API. HTTP tidak dirancang dengan mempertimbangkan REST. Selain itu, REST menerima transmisi data ini sebagai kriteria untuk aplikasi yang sadar akan REST. Untuk menggunakan HTTP dengan REST API, klien mengirimkan permintaan dalam format yang mungkin Anda kenal. Permintaan sinyal video ke API YouTube, misalnya, terlihat seperti ini:
- Gunakan perintah GET untuk mendapatkan sumber daya.
- Gunakan perintah POST untuk membuat sumber daya baru
- Gunakan instruksi PUT untuk membuat perubahan atau terus memperbarui sumber daya yang ada
- Gunakan permintaan DELETE untuk menyingkirkan sumber daya.
Metode HTTP menentukan tindakan yang dimaksudkan untuk diambil terkait dengan sumber daya tertentu. Metode HTTP juga dikenal sebagai kata kerja HTTP.
URL-nya adalah HTTP
Pengidentifikasi sumber daya seragam, atau URI, yang mengidentifikasi sumber daya yang dimaksud terdapat dalam URL. URL juga merupakan titik akhir dalam skenario ini karena di situlah RESTful API bersentuhan dengan pengguna layanan.
String kueri: URL menyertakan string kueri. String kueri digunakan untuk mendefinisikan parameter, yang diberi nilai.
Setelah menerima dan memverifikasi permohonan, server web mengembalikan data pada sumber daya yang ditargetkan. Biasanya, data dikembalikan dalam struktur yang dikenal sebagai JSON (JavaScript Object Notation). JSON menyajikan semua komponen sumber daya dalam format portabel yang dapat dibaca dengan mudah oleh Manusia.
Prinsip antarmuka seragam
Antarmuka yang seragam harus mengikuti parameter berikut:
HATEOAS: Hypermedia sebagai mesin status aplikasi
Hypermedia adalah mesin di balik layanan web RESTful. Ini menunjukkan bahwa hypermedia adalah semua yang ingin dipahami pelanggan untuk mengenali jawaban penyedia.
- Hanya URI pertama aplikasi klien yang harus diberikan kepada klien. Aplikasi klien harus terus mengarahkan semua materi dan aktivitas lain menggunakan hyperlink.
- Layanan web RESTful tidak memerlukan bahasa kueri input (IDL), yang berbeda dari API lainnya
Jenis media adalah nama untuk format data representasi. Jenis media mengidentifikasi definisi yang menguraikan bagaimana penggambaran harus diperlakukan. Web API yang menggunakan REST tampak seperti hypertext. Setiap item data yang dapat dialamatkan memiliki lokasi, baik secara langsung (seperti melalui tautan dan properti identitas) atau secara implisit (mis., berasal dari struktur deskripsi tipe media).
Pesan deskripsi diri
Setiap komunikasi antara sisi klien dan sisi server harus menyediakan data yang cukup untuk menjalankan komunikasi. Dengan demikian, permintaan dari sisi klien ke sisi server perlu menentukan sumber daya yang coba diakses bersama dengan tujuan spesifiknya.
Selain itu, penggambaran sumber daya harus deskriptif; pengguna tidak harus menyadari apakah sumber daya adalah orang atau peralatan. Sebaliknya, itu harus merespons mengikuti jenis media yang terhubung ke bantuan.
Oleh karena itu, tidak dapat disangkal, kami akan mengembangkan banyak jenis media yang unik, seringkali satu jenis media per sumber daya. Setiap bentuk media menentukan paradigma produksi standar. Misalnya, HTML mendefinisikan bagaimana hypertext ditampilkan dan bagaimana browser menangani setiap komponen.Mengidentifikasi sumber daya
Sumber daya yang dimaksud dalam komunikasi belakang antara pelanggan dan server harus dikenali menggunakan penggambaran. Berpegang pada sistem Uniform Resource Identifier (URI) diperbolehkan untuk ini. Dengan kata lain, komunikasi dari server ke pelanggan mungkin termasuk versi HTML dari dokumen dan beberapa informasi daripada file nyata dari penyimpanan server.
Konsumen dapat dengan mudah memahami versi HTML karena mengikuti pola URI. Pelanggan harus memodifikasi sumber daya dengan memberikan server gambaran tentang bagaimana sumber daya pada akhirnya akan muncul. Ini akan memungkinkan pengguna untuk membangun, mengambil, memodifikasi, dan menghapus sumber daya. Jika pelanggan memiliki otorisasi yang diperlukan untuk mengubah data, server harus memenuhi permintaan.
Tanpa kewarganegaraan
Dengan RESTful API, semua permintaan klien harus bersifat sementara. Akibatnya, setiap badan kueri dan respons menyertakan semua data yang diperlukan untuk menyelesaikan kontrak, membuat setiap koneksi menjadi otonom. Server tidak melacak permintaan HTTP sebelumnya; itu memperlakukan masing-masing yang dibuat oleh klien sebagai kueri yang sama sekali baru.
Karena server tidak harus melakukan tugas tambahan apa pun untuk mendapatkan data historis, transport tanpa kewarganegaraan secara signifikan meminimalkan jumlah penyimpanan yang diperlukan untuk server dan meningkatkan kemungkinan bahwa respons akan diterima. Ini menjamin skalabilitas interaksi ini: pemrogram tidak perlu khawatir menggunakan lebih banyak penyimpanan atau membebani server saat perangkat lunak mereka berkembang dan membuat permintaan HTTP.
berlapis
Sejauh ini kami telah mendefinisikan kueri API web sebagai pertukaran klien-server langsung, meskipun ini sedikit terlalu menyederhanakan. Di antara kedua organisasi ini, seringkali ada lebih banyak server. Platform ini, atau lapisan, berada di tempat untuk mengelola dan membubarkan lalu lintas, menambah perlindungan, dan melakukan berbagai tugas penting lainnya.
Menurut konsep ini, pesan yang dikirim antara pengguna dan server target harus terstruktur dan ditangani dengan cara yang sama, terlepas dari lapisan yang ada di antaranya. Lapisan ekstra harus baik-baik saja dengan interaksi pelanggan. Pemrogram yang mematuhi aturan ini dapat mengubah sistem server tanpa memengaruhi proses permintaan-tanggapan yang mendasar.
Dapat disimpan dalam cache
Caching terjadi saat pelanggan menelusuri situs web saat konten disimpan di mesin pelanggan. Materi yang di-cache dimuat dengan cepat dari memori internal daripada diunduh lagi dari server saat pengguna mengunjungi situs itu nanti. Sebagian besar situs besar menggunakan caching untuk mengurangi pemuatan halaman sambil menghemat ruang server dan bandwidth.
Caching data dipertimbangkan saat mengembangkan REST API. Respons yang diberikan server kepada pelanggan harus menyatakan jika dan sejauh mana sumber daya yang diberikan dapat disimpan.
Dalam Kode Permintaan
Prinsip REST terakhir tidak diperlukan. Jika diminta, respons API dapat menyertakan kode perangkat lunak untuk digunakan klien. Karena itu, pelanggan dapat menjalankan aplikasi atau program klien di backendnya.
API dianggap sebagai RESTful API jika mematuhi serangkaian pedoman ini. Panduan ini, bagaimanapun, memberikan banyak kebebasan kepada programmer untuk memodifikasi fitur dari RESTful API mereka. REST API berbeda dari Simple Object Access Protocol, teknik API web populer lainnya, karena lebih fleksibel (SOAP).
Konsensus Titik Akhir
Pertimbangkan titik akhir ini:
- /pengguna/123\s
- /pengguna/id/123\s
- /pengguna/123\s/pengguna/id/123\s
- /pengguna/?id=123
Semua adalah metode yang sah untuk klien 123 untuk mengambil data. Ketika ada prosedur yang lebih rumit, jumlah kemungkinan bertambah. Misalnya, dalam urutan terbalik mulai dari entri 51, tampilkan 10 orang dengan nama belakang yang dimulai dengan "A" dan beroperasi untuk perusahaan.
Pada akhirnya, tidak peduli bagaimana Anda menyusun URL; keseragaman di seluruh RESTful API Anda penting. Pada sistem perangkat lunak besar dengan banyak pemrogram, itu tidak mudah. Modifikasi RESTful API tidak dapat dihindari, tetapi URL endpoint tidak boleh ditolak karena hal itu akan menyebabkan aplikasi yang bergantung padanya berhenti bekerja.
Versi REST API
Membuat versi API adalah praktik umum untuk mencegah ketidakcocokan. Sebagai ilustrasi, /2.0/user/123 menggantikan /user/123. Titik akhir lama dan baru dapat terus berfungsi. Akibatnya, ini memaksa kebutuhan akan API penting di masa lalu untuk dipertahankan. Versi sebelumnya pada akhirnya dapat dihentikan, tetapi prosedurnya perlu dipikirkan dengan cermat.
Otentikasi REST API
Perangkat apa pun dapat mengunduh sindiran tanpa otorisasi menggunakan API penyelidikan. API yang membaca informasi pribadi atau mengizinkan pengeditan dan penghapusan kueri tidak mendukung ini. Program sisi klien dalam domain yang sama dengan layanan web RESTful dikirim dan menerima cookie dengan cara yang sama seperti permintaan HTTP. (Harap diperhatikan bahwa hak istimewa memulai ulang opsi harus ditentukan di situs sebelumnya untuk Fetch().) Kueri API dapat diverifikasi untuk mengonfirmasi bahwa pengguna telah masuk dan memiliki izin yang diperlukan.
Otentikasi dasar HTTP : Program pihak ketiga harus menggunakan solusi persetujuan yang berbeda. Beberapa metode otentikasi yang populer adalah verifikasi utama untuk:
- HTTP. Nama pengguna yang disandikan base64: string kata sandi diberikan di bidang kueri sebagai bagian dari header Persetujuan HTTP.
- Kunci API: Dengan menyediakan kunci API RESTful yang mungkin memiliki izin khusus atau terbatas pada satu situs, API tersedia untuk aplikasi pihak ketiga. Setiap pesan berisi kunci baik pada string kueri atau di header HTTP. (String kueri adalah komponen URL).
- OAuth: Sebelum membuat permintaan apa pun, ID pelanggan dan mungkin rahasia pelanggan dikirim ke server OAuth untuk mendapatkan kredensial. Hingga masa berlakunya habis, identitas OAuth kemudian ditransmisikan bersama dengan setiap permintaan API.
- Token Internet di JSON (JWT): Header kueri dan header respons menyampaikan kredensial pengguna yang ditandatangani secara digital dengan aman. JWT memungkinkan server untuk mengenkripsi hak akses, menghilangkan kebutuhan untuk query database atau menggunakan mekanisme otentikasi lain.
Skenario penggunaan akan memengaruhi cara API diautentikasi:
- Terkadang, program pihak ketiga ditangani seperti klien masuk lainnya dengan hak istimewa dan hak yang sama. Misalnya, API peta mungkin menyediakan program permintaan dengan instruksi di antara dua titik. Itu harus memverifikasi bahwa program adalah pengguna yang sah, tetapi tidak harus memverifikasi kredensial klien.
- Dalam situasi lain, program pihak ketiga meminta informasi pribadi dari pengguna tertentu, seperti konten email. REST API harus mengenali klien dan izinnya, tetapi mereka tidak perlu peduli dengan program pemanggilan.
Keamanan API REST
Layanan web RESTful menambahkan cara lebih lanjut untuk berinteraksi dengan dan memengaruhi perangkat lunak Anda. Bahkan jika host Anda bukan tujuan peretasan yang tinggi, pengguna yang berperilaku buruk dapat mengirimkan ratusan permintaan per detik dan menutupnya. Artikel ini tidak mencakup keamanan, tetapi prosedur standar terbaik meliputi:
Manfaatkan HTTPS
Gunakan mekanisme otentikasi yang kuat
CORS dapat digunakan untuk membatasi panggilan pelanggan ke area tertentu.
Sediakan kebutuhan kemampuan — yaitu, jangan
Hasilkan pilihan DELETE yang tidak perlu; verifikasi semua URL Endpoint dan informasi isi.
Blokir tautan dari sektor atau alamat IP yang tidak dikenal dengan tidak memasukkan voucher API di JavaScript sisi klien.
Paket-paket besar yang tidak normal diblokir.
Pikirkan tentang pembatasan tarif, di mana permintaan dari alamat IP atau kredensial API yang sama dibatasi hingga N kueri per menit.
Respons dengan kode status HTTP yang tepat, kueri log header cache, dan investigasi yang gagal
Banyak permintaan dan data yang tidak perlu
Penyebaran layanan web RESTful memiliki keterbatasan. Ada kemungkinan bahwa respons memiliki lebih banyak informasi daripada yang Anda minta atau beberapa permintaan diperlukan untuk mendapatkan semua informasi. Pikirkan tentang layanan web RESTful yang memberi pengguna akses ke informasi pembuat dan buku; klien dapat:
- Mintalah informasi 10 buku pertama, tercantum dalam urutan pembelian (penjual teratas terlebih dahulu). Koleksi buku, bersama dengan ID masing-masing penulis, termasuk dalam jawaban.
Untuk mengambil informasi untuk setiap penulis, buat hingga 10 kueri /penulis/id.
N kueri API harus dibuat untuk setiap respons terhadap kueri induk, yang dicirikan sebagai "masalah N+1".
Jika ini adalah situasi yang sering digunakan, layanan web RESTful mungkin dimodifikasi untuk memasukkan semua informasi penulis untuk setiap buku yang dihasilkannya, termasuk nama, jenis kelamin, kebangsaan, biografi, dan sebagainya. Bahkan lebih banyak informasi tentang buku-buku mereka sebelumnya dapat diberikan, meskipun doing sehingga akan secara signifikan meningkatkan beban respons. API dapat diubah untuk membuat informasi penulis opsional. Detail penulis=penuh untuk mencegah jawaban besar yang tidak perlu. Banyaknya opsi yang harus didukung oleh desainer API mungkin sangat banyak.
Membungkus
Anda sekarang benar-benar memahami REST API, bagaimana REST API beroperasi, contoh REST API, untuk apa REST API digunakan, batasan arsitektur, dan topik lain yang tercakup dalam tutorial ini. Pemrogram mungkin merasa belajar tentang API sulit dan menakutkan, tetapi platform tanpa kode AppMaster telah membuat perpustakaan REST API baru yang dapat diakses di mana Anda dapat memperdalam kesadaran Anda tentang berbagai API REST untuk mendukung pengembangan profesional Anda lebih lanjut.
Di AppMaster, kami mencoba meningkatkan aksesibilitas dan kegunaan API. Kami ingin Anda mempelajari, bereksperimen, dan menyadari manfaat menggunakan perangkat lunak API dalam karier dan kehidupan pribadi Anda. Untuk membantu Anda mendesain API web yang lebih baik dengan lebih cepat, AppMaster meningkatkan kolaborasi dan mengotomatiskan setiap tahap siklus hidup API. Teruslah membuat, memajukan, dan memperluas pemahaman Anda tentang REST API.
