Sebelum saya mempelajari pembangunan perisian, API terdengar seperti bir.
Hari ini saya sering menggunakan istilah itu sehingga saya sebenarnya baru-baru ini cuba memesan API di bar.
Respons bartender adalah membuang sumber 404: tidak dijumpai.
Saya berjumpa dengan banyak orang, baik yang bekerja di bidang teknologi dan di tempat lain, yang mempunyai idea yang agak kabur atau tidak betul mengenai maksud istilah yang cukup umum ini.
Secara teknikal, API bermaksud Antaramuka Pengaturcaraan Aplikasi . Pada tahap tertentu, kebanyakan syarikat besar telah membina API untuk pelanggan mereka, atau untuk kegunaan dalaman.
Tetapi bagaimana anda menerangkan API dalam bahasa Inggeris biasa? Dan adakah makna yang lebih luas daripada yang digunakan dalam pembangunan dan perniagaan? Pertama, mari kita tarik kembali dan melihat bagaimana web itu sendiri berfungsi.
WWW dan pelayan jauh
Apabila saya berfikir tentang Web, saya membayangkan rangkaian pelayan yang bersambung besar .
Setiap halaman di internet disimpan di suatu tempat di pelayan jauh. Pelayan jauh tidak begitu mistik - hanya sebahagian daripada komputer yang berada jauh yang dioptimumkan untuk memproses permintaan.
Untuk meletakkan sesuatu dalam perspektif, anda boleh menjana pelayan di komputer riba anda yang mampu melayani keseluruhan laman web ke Web (sebenarnya, pelayan tempatan adalah yang digunakan jurutera untuk membangunkan laman web sebelum melancarkannya kepada umum).
Apabila anda mengetik www.facebook.com ke dalam penyemak imbas anda, permintaan akan dihantar ke pelayan jauh Facebook. Setelah penyemak imbas anda menerima respons, ia menafsirkan kod dan memaparkan halaman.
Untuk penyemak imbas, juga dikenali sebagai pelanggan , pelayan Facebook adalah API. Ini bermaksud bahawa setiap kali anda mengunjungi halaman di Web, anda berinteraksi dengan beberapa API pelayan jauh.
API tidak sama dengan pelayan jarak jauh - melainkan bahagian pelayan yang menerima permintaan dan mengirim respons .
API sebagai cara untuk melayani pelanggan anda
Anda mungkin pernah mendengar syarikat mengemas API sebagai produk. Sebagai contoh, Weather Underground menjual akses ke API data cuaca.
Contoh senario: Laman web perniagaan kecil anda mempunyai borang yang digunakan untuk mendaftar pelanggan untuk membuat janji temu. Anda ingin memberi klien anda kemampuan untuk membuat acara kalendar Google secara automatik dengan perincian janji temu tersebut.
Penggunaan API: Ideanya adalah agar pelayan laman web anda bercakap terus dengan pelayan Google dengan permintaan untuk membuat acara dengan perincian yang diberikan. Pelayan anda kemudian akan menerima respons Google, memprosesnya, dan mengirim kembali maklumat yang relevan ke penyemak imbas, seperti mesej pengesahan kepada pengguna.
Sebagai alternatif, penyemak imbas anda sering dapat menghantar permintaan API terus ke pelayan Google dengan melewati pelayan anda.
Bagaimanakah API Kalendar Google ini berbeza dengan API pelayan jauh lain di luar sana?
Dari segi teknikal , perbezaannya adalah format permintaan dan respons.
Untuk membuat keseluruhan laman web, penyemak imbas anda mengharapkan respons dalam HTML, yang mengandungi kod persembahan, sementara panggilan API Kalendar Google hanya akan mengembalikan data - kemungkinan dalam format seperti JSON .
Sekiranya pelayan laman web anda membuat permintaan API, maka pelayan laman web anda adalah klien (serupa dengan penyemak imbas anda yang menjadi pelanggan ketika anda menggunakannya untuk menavigasi ke laman web).
Dari perspektif pengguna anda, API membolehkan mereka menyelesaikan tindakan tanpa meninggalkan laman web anda.
Sebilangan besar laman web moden menggunakan sekurang-kurangnya beberapa API pihak ketiga.
Banyak masalah sudah mempunyai penyelesaian pihak ketiga, baik itu dalam bentuk perpustakaan atau perkhidmatan. Selalunya lebih mudah dan lebih dipercayai untuk menggunakan penyelesaian yang ada.
Tidak jarang pasukan pengembangan memecah aplikasi mereka menjadi beberapa pelayan yang saling bercakap melalui API. Pelayan yang menjalankan fungsi pembantu untuk pelayan aplikasi utama biasanya disebut sebagai perkhidmatan mikro .
Ringkasnya, apabila syarikat menawarkan API kepada pelanggan mereka, itu hanya bermaksud bahawa mereka telah membuat sekumpulan URL khusus yang mengembalikan respons data murni - yang bermaksud bahawa respons tidak akan mengandungi jenis overhead persembahan yang anda harapkan dalam antara muka pengguna grafik seperti laman web .
Bolehkah anda membuat permintaan ini dengan penyemak imbas anda? Selalunya, ya. Oleh kerana penghantaran HTTP sebenarnya berlaku dalam teks, penyemak imbas anda akan sentiasa melakukan yang terbaik untuk memaparkan respons.
Sebagai contoh, anda boleh mengakses API GitHub secara langsung dengan penyemak imbas anda tanpa memerlukan token akses. Inilah respons JSON yang anda dapat ketika anda mengunjungi laluan API pengguna GitHub di penyemak imbas anda (//api.github.com/users/petrgazarov):
{ "login": "petrgazarov", "id": 5581195, "avatar_url": "//avatars.githubusercontent.com/u/5581195?v=3", "gravatar_id": "", "url": "//api.github.com/users/petrgazarov", "html_url": "//github.com/petrgazarov", "followers_url": "//api.github.com/users/petrgazarov/followers", "following_url": "//api.github.com/users/petrgazarov/following{/other_user}", "gists_url": "//api.github.com/users/petrgazarov/gists{/gist_id}", "starred_url": "//api.github.com/users/petrgazarov/starred{/owner}{/repo}", "subscriptions_url": "//api.github.com/users/petrgazarov/subscriptions", "organizations_url": "//api.github.com/users/petrgazarov/orgs", "repos_url": "//api.github.com/users/petrgazarov/repos", "events_url": "//api.github.com/users/petrgazarov/events{/privacy}", "received_events_url": "//api.github.com/users/petrgazarov/received_events", "type": "User", "site_admin": false, "name": "Petr Gazarov", "company": "PolicyGenius", "blog": "//petrgazarov.com/", "location": "NYC", "email": "[email protected]", "hireable": null, "bio": null, "public_repos": 23, "public_gists": 0, "followers": 7, "following": 14, "created_at": "2013-10-01T00:33:23Z", "updated_at": "2016-08-02T05:44:01Z"}Penyemak imbas nampaknya telah menunjukkan paparan JSON dengan baik. Respons JSON seperti ini siap digunakan dalam kod anda. Sangat mudah untuk mengekstrak data dari teks ini. Kemudian anda boleh melakukan apa sahaja yang anda mahukan dengan data.
A adalah untuk "Aplikasi"
Untuk menutup, mari kita masukkan beberapa contoh API.
"Aplikasi" boleh merujuk kepada banyak perkara. Berikut adalah beberapa daripadanya dalam konteks API:
- Sekeping perisian dengan fungsi yang berbeza.
- Seluruh pelayan, keseluruhan aplikasi, atau hanya sebahagian kecil aplikasi.
Pada dasarnya setiap perisian yang dapat dipisahkan dari persekitarannya, dapat menjadi "A" dalam API, dan mungkin juga akan memiliki semacam API.
Katakan anda menggunakan perpustakaan pihak ketiga dalam kod anda. Setelah dimasukkan ke dalam kod anda, perpustakaan menjadi sebahagian daripada keseluruhan aplikasi anda. Sebagai perisian yang berbeza, perpustakaan mungkin mempunyai API yang membolehkannya berinteraksi dengan kod anda yang lain.
Inilah contoh lain: Dalam Reka Bentuk Berorientasikan Objek , kod disusun menjadi objek. Aplikasi anda mungkin mempunyai ratusan objek yang boleh saling berinteraksi.
Setiap objek mempunyai API - satu set awam kaedah dan ciri-ciri yang ia gunakan untuk berinteraksi dengan objek lain dalam permohonan anda.
An object may also have inner logic that is private, meaning that it’shiddenfrom the outside scope (and not an API).
From what we have covered, I hope you take away the broader meaning of API as well as the more common uses of the term today.
Interesting Resources (stuff that I left out but is still very cool):
A great youtube video on DNS (Domain Name System)
HTTP protocol basics
An Awesome Khan Academy video on Object Oriented Design Principles