
Istirahat adalah akronim untuk transfer negara representasional . RESTFUL API adalah gaya arsitektur untuk Antarmuka Program Aplikasi (API) yang menggunakan permintaan HTTP untuk mengakses dan mengubah data. Data itu dapat digunakan untuk mendapatkan, menempatkan, memposting, dan menghapus tipe data, yang mengacu pada membaca, memperbarui, membuat, dan menghapus operasi tentang sumber daya. Untuk lebih jelasnya
Fungsi utama yang digunakan dalam arsitektur berbasis istirahat adalah:
Aplikasi Anda harus memenuhi kendala atau prinsip tertentu. Mari kita membahas detail tentang prinsip -prinsip ini.
Ada enam prinsip tanah, di bawah ini adalah enam prinsip penuntun dari:
Stateless: Permintaan yang dikirim dari klien ke server berisi semua informasi yang diperlukan yang diperlukan untuk sepenuhnya memahaminya. Ini bisa menjadi bagian dari URI, parameter query-string, tubuh, atau bahkan header. URI digunakan untuk secara unik mengidentifikasi sumber daya dan tubuh memegang keadaan sumber daya yang meminta. Setelah pemrosesan dilakukan oleh server, respons yang tepat dikirim kembali ke klien melalui header, status atau badan respons.
Client-Server: Ini memiliki antarmuka seragam yang memisahkan klien dari server. Memisahkan kekhawatiran membantu dalam meningkatkan portabilitas antarmuka pengguna di berbagai platform serta meningkatkan skalabilitas komponen server.
Antarmuka Uniform: Untuk mendapatkan keseragaman di seluruh aplikasi, REST telah mendefinisikan empat kendala antarmuka yaitu:
Resource identification
Resource Manipulation using representations
Self-descriptive messages
Hypermedia as the engine of application state
Cacheable: Untuk memberikan kinerja yang lebih baik, aplikasi sering dibuat cache. Ini dilakukan dengan memberi label respons dari server sebagai yang dapat di-cache atau tidak dapat dicap secara implisit atau eksplisit. Jika respons didefinisikan sebagai cache, maka cache klien dapat menggunakan kembali data respons untuk respons yang setara di masa depan. Ini juga membantu dalam mencegah penggunaan kembali data basi.
Lapisan Sistem: Arsitektur sistem berlapis memungkinkan aplikasi menjadi lebih stabil dengan membatasi perilaku komponen. Arsitektur ini memungkinkan penyeimbangan beban dan menyediakan cache bersama untuk mempromosikan skalabilitas. Arsitektur berlapis juga membantu dalam meningkatkan keamanan aplikasi karena komponen di setiap lapisan tidak dapat berinteraksi di luar lapisan langsung berikutnya.
Kode sesuai permintaan: Kode sesuai permintaan adalah kendala opsional dan paling sedikit digunakan. Ini memungkinkan kode klien atau applet untuk diunduh dan diperpanjang melalui antarmuka yang akan digunakan dalam aplikasi. Intinya, ini menyederhanakan klien dengan membuat aplikasi pintar yang tidak bergantung pada struktur kode sendiri.
Sekarang setelah Anda tahu apa itu API REST dan apa yang Anda butuhkan untuk memberikan aplikasi yang efisien, mari selami lebih dalam dan lihat proses membangun API REST menggunakan semua teknologi tren dan frameowrks.
Istirahat dan Protokol Akses Objek Sederhana (SOAP) menawarkan berbagai metode untuk memohon layanan web. Istirahat adalah gaya arsitektur, sedangkan SOAP mendefinisikan spesifikasi protokol komunikasi standar untuk pertukaran pesan berbasis XML. Aplikasi istirahat dapat menggunakan sabun.
Layanan web yang tenang tidak memiliki kewarganegaraan. Implementasi berbasis istirahat sederhana dibandingkan dengan SOAP, tetapi pengguna harus memahami konteks dan konten yang dilewati, karena tidak ada set aturan standar untuk menggambarkan antarmuka layanan web REST. Layanan REST berguna untuk perangkat profil terbatas, seperti seluler, dan mudah diintegrasikan dengan situs web yang ada.
SOAP membutuhkan lebih sedikit kode pipa yang berarti kode infrastruktur tingkat rendah yang menghubungkan modul kode utama bersama-sama daripada desain layanan REST. Bahasa Deskripsi Layanan Web menjelaskan seperangkat aturan umum untuk menentukan pesan, binding, operasi, dan lokasi Layanan. Layanan web SOAP berguna untuk pemrosesan dan doa yang tidak sinkron.
Ini adalah beberapa poin yang harus Anda pertimbangkan saat mengembangkan REST API:
Payload data respons yang sangat besar akan memperlambat penyelesaian permintaan, panggilan layanan lainnya, dan dalam mempengaruhi kinerja degrade. Seperti yang Anda ketahui, sekarang kami mengembalikan semua pesanan untuk pelanggan sebagai lawan dari pesanan mereka saat ini, kami harus berurusan dengan beberapa penurunan kinerja.
Kami dapat menggunakan GZip Compression untuk mengurangi ukuran muatan kami. Ini mengurangi ukuran unduhan respons kami di aplikasi web (sisi klien), serta meningkatkan kecepatan unggah, atau pembuatan beberapa entitas (pesanan). Kita dapat menggunakan Deflate compression pada API web. Atau, kami dapat memperbarui header accodingRequest ke GZIP .
Caching adalah salah satu metode termudah untuk meningkatkan kinerja API. Jika kami memiliki permintaan yang sering memberikan kembali respons yang sama, maka versi yang di -cache dari respons itu membantu menghindari panggilan layanan tambahan/kueri database . Anda akan ingin memastikan ketika menggunakan caching untuk secara berkala membatalkan data dalam cache, terutama ketika pembaruan data baru terjadi.
Katakanlah pelanggan kami ingin melakukan pemesanan untuk bagian mobil, dan aplikasi kami memanggil beberapa API suku cadang mobil untuk mengambil harga bagian. Karena respons (harga bagian) hanya berubah sekali setiap minggu (@ 1:00 pagi), kita dapat menyimpan respons untuk sisa waktu sampai saat itu. Ini menyelamatkan kita dari melakukan panggilan baru setiap kali untuk mengembalikan harga bagian yang sama. Kasus serupa Anda dapat menggunakan cache untuk menghindari panggilan atau permintaan tambahan.
Jaringan yang lambat akan menurunkan kinerja bahkan API yang paling dirancang dengan kuat. Jaringan yang tidak dapat diandalkan dapat menyebabkan downtime, yang dapat menyebabkan organisasi Anda melanggar SLA, ketentuan layanan, dan janji yang mungkin Anda buat kepada pelanggan Anda. Penting untuk berinvestasi dalam infrastruktur jaringan yang tepat, sehingga kami dapat mempertahankan tingkat kinerja yang diinginkan. Ini dapat dicapai dengan memanfaatkan dan membeli sumber daya cloud yang memadai dan infrastruktur (example: in AWS, allocate the proper # of EC2 instances, use a Network Load Balancer) . Juga, jika Anda memiliki sejumlah besar proses latar belakang, jalankan yang ada di utas terpisah untuk menghindari permintaan pemblokiran. Anda juga dapat menggunakan cermin, dan jaringan pengiriman konten (CDN) seperti CloudFront untuk melayani permintaan lebih cepat di berbagai bagian dunia.
Anda dapat memiliki situasi di mana API Anda menderita serangan DDOS yang bisa berbahaya dan disengaja, atau tidak intelisional ketika seorang insinyur memanggil API untuk dieksekusi pada loop dari beberapa aplikasi lokal. Anda dapat menghindari ini dengan mengukur transaksi, dan monitoring the number of how many transactions occur per IP Address, or per SSO/JWT Token (if the customer/calling app is authorized before calling the API) .
Metode untuk pembatasan tingkat ini membantu mengurangi permintaan berlebihan yang akan memperlambat API, membantu menangani panggilan/eksekusi yang tidak disengaja, dan secara proaktif memantau dan mengidentifikasi kemungkinan aktivitas berbahaya.
Ini adalah kesalahpahaman yang umum di antara para insinyur yang menempatkan dan merapikan operasi menghasilkan hasil yang sama. Mereka serupa dalam memperbarui sumber daya, tetapi mereka masing -masing melakukan pembaruan secara berbeda. Masukkan sumber daya pembaruan operasi dengan mengirimkan pembaruan ke seluruh sumber daya. Operasi tambalan menerapkan pembaruan parsial hanya untuk sumber daya yang perlu diperbarui. Panggilan inpatch yang dihasilkan yang menghasilkan muatan yang lebih kecil, dan meningkatkan kinerja pada skala.
Pro-Tip: Even though PATCH calls can limit the request size, you should note that it is not Idempotent.
Meaning, it is possible that a PATCHcan yield different results with a series of multiple calls.
So, you should carefully and deliberately consider your application for using PATCH requests,
and make sure that they are idempotently implemented if needed. If not, use PUT requests.
Ini mungkin salah satu tips terpenting yang akan Anda baca di sini. Jika ada satu hal yang harus Anda pelajari dari repo ini, seharusnya ini! Tidak ada negosiasi yang satu ini.
Memiliki log, pemantauan, dan peringatan membantu insinyur mendiagnosis dan memulihkan masalah sebelum menjadi masalah . Banyak API (Express/Node berbasis, Java, GO) memiliki titik akhir yang telah ditentukan untuk menilai hal-hal seperti:
`/health`
`/metrics`
Jika Anda tidak memiliki logging diaktifkan, dan ada masalah potensial yang terjadi, Anda tidak akan dapat melacak asal, atau di mana masalahnya terjadi dalam permintaan tertentu.
Jika Anda tidak memiliki pemantauan yang diaktifkan, Anda tidak akan tahu dari perspektif analitik seberapa sering beberapa masalah atau kesalahan terjadi. Yang kemudian akan mencegah Anda memikirkan solusi yang mungkin.
Dan ... jika Anda tidak memiliki peringatan yang diaktifkan, Anda tidak akan tahu apakah ada masalah, sampai pelanggan (atau lebih buruk, pelanggan) melaporkannya.
Pagination membantu membuat ember konten dari berbagai tanggapan . Optimalisasi semacam ini membantu meningkatkan respons sambil melestarikan data yang ditransfer/ditampilkan kepada pelanggan. Anda dapat menstandarkan, segmen, dan membatasi respons yang membantu mengurangi kompleksitas hasil, dan meningkatkan pengalaman pelanggan secara keseluruhan dengan memberikan respons/hasil hanya untuk apa yang diminta pelanggan.
Kita tahu bahwa API luar biasa, dan bisa sangat kuat dalam memberikan bisnis dan pelanggan pengalaman hebat, jika dioptimalkan dan ditingkatkan dengan benar untuk kinerja. Persyaratan bisnis dan harapan pelanggan selalu berkembang seiring waktu. Dan sebagai insinyur yang bertanggung jawab, terserah kita dalam memutuskan bagaimana membangun API kita secara berkinerja, yang dapat membantu kita mencapai dan melampaui tujuan kita.
Kiat -kiat ini hanyalah puncak gunung es, dan berlaku untuk semua API dalam pengaturan umum. Bergantung pada API khusus Anda dan kasus penggunaan, layanan apa yang berinteraksi dengannya, seberapa sering ia dipanggil, dari tempat yang dipanggil, dll. Anda mungkin harus mengimplementasikan tips ini dengan cara yang berbeda.
Istirahat API dengan Laravel - Paspor
Istirahat API dengan PHP - Ups
REST API dengan Python - Flask
REST API dengan Python - Django - Restframework
Istirahat API dengan go - mux
Istirahat API dengan go - gin
REST API dengan NodeJs - Express - Basic
REST API dengan NodeJS - Express- JWT - Sequellze - Advance
Sangat mudah untuk membuat API REST dalam beberapa menit, Anda dapat memilih basis kode di atas sesuai dengan preferensi bahasa dan kerangka kerja Anda dan mengikuti instruksi untuk membuat API REST.
Happy Coding?
LinkedIn: https://www.linkedin.com/in/the-startup-cto/
Medium: https://apige.medium.com/
Twitter: https://twitter.com/htngapi