Pengertian
Session Layer
Lapisan sesi atau Session layer adalah lapisan kelima
dari bawah dalam model referensi jaringan OSI, yang mengizinkan sesi koneksi
antara node dalam sebuah jaringan dibuat atau dihancurkan. Lapisan sesi tidak
tahu menahu mengenai efisiensi dan keandalan dalam transfer data antara
node-node tersebut, karena fungsi-fungsi tersebut disediakan oleh empat lapisan
di bawahnya dari dalam model OSI (lapisan fisik, lapisan data-link, lapisan
jaringan dan lapisan transport). Lapisan sesi bertanggung jawab untuk melakukan
sinkronisasi antara pertukaran data antar komputer, membuat struktur sesi
komunikasi, dan beberapa masalah yang berkaitan secara langsung dengan
percakapan antara node-node yang saling terhubung di dalam jaringan. Lapisan
ini juga bertanggung jawab untuk melakukan fungsi pengenalan nama pada tingkat
nama jaringan logis dan juga menetapkan [[[port TCP|port-port komunikasi]].
Sebagai contoh, protokol NetBIOS dapat dianggap sebagai sebuah protokol yang
berjalan pada lapisan ini.
Lapisan sesi dari model OSI tidak banyak
diimplementasikan di dalam beberapa protokol jaringan populer, seperti halnya
TCP/IP atau IPX/SPX . Akan tetapi, tiga lapisan tertinggi di dalam model
OSI (lapisan sesi, lapisan presentasi , dan lapisan aplikasi ) seringnya
disebut sebagai sebuah kumpulan yang homogen, sebagai sebuah lapisan aplikasi
saja.
Session layer mengijinkan para pengguna untuk
menetapkan session dengan pengguna lainnya. Sebuah session selain memungkinkan
transport data biasa, seperti yang dilakukan oleh transport layer, juga
menyediakan layanan yang istimewa untuk aplikasi-aplikasi tertentu. Sebuah
session digunakan untuk memungkinkan seseorang pengguna log ke remote
timesharing system atau untuk memindahkan file dari satu mesin kemesin lainnya.
Sebuah layanan session layer adalah untuk melaksanakan
pengendalian dialog. Session dapat memungkinkan lalu lintas bergerak dalam
bentuk dua arah pada suatu saat, atau hanya satu arah saja. Jika pada satu saat
lalu lintas hanya satu arah saja (analog dengan rel kereta api tunggal),
session layer membantu untuk menentukan giliran yang berhak menggunakan saluran
pada suatu saat.
Layanan session di atas disebut manajemen token. Untuk
sebagian protokol, adalah penting untuk memastikan bahwa kedua pihak yang
bersangkutan tidak melakukan operasi pada saat yang sama. Untuk mengatur
aktivitas ini, session layer menyediakan token-token yang dapat digilirkan.
Hanya pihak yang memegang token yang diijinkan melakukan operasi kritis.
Layanan session lainnya adalah sinkronisasi. Ambil
contoh yang dapat terjadi ketika mencoba transfer file yang berdurasi 2 jam
dari mesin yang satu ke mesin lainnya dengan kemungkinan mempunyai selang waktu
1 jam antara dua crash yang dapat terjadi. Setelah masing-masing transfer
dibatalkan, seluruh transfer mungkin perlu diulangi lagi dari awal, dan mungkin
saja mengalami kegagalan lain. Untuk mengurangi kemungkinan terjadinya masalah
ini, session layer dapat menyisipkan tanda tertentu ke aliran data. Karena itu
bila terjadi crash, hanya data yang berada sesudah tanda tersebut yang akan
ditransfer ulang.
Pengertian socket adalah interface pada jaringan yang
menjadi titik komunikasi antarmesin pada Internet Protocol, dan tentunya tanpa
komunikasi ini, tidak akan ada pertukaran data dan informasi jaringan. Socket
terdiri dari elemen-elemen utama sebagai berikut:
(1) Protokol.
(2) Local IP.
(3) Local Port.
(4) Remote IP.
(5) Remote Port.
Komunikasi socket jaringan memang tidak mengenal
lelah, pertukaran data terjadi terus-menerus dan memegang peranan vital.
Bayangkan sebuah server game online yang berkomunikasi
tanpa henti, dimainkan oleh entah berapa banyak client yang tersebar. Ini
merupakan salah satu contoh aplikasi dari sekian banyak aplikasi yang
menggunakan socket jaringan untuk saling berkomunikasi dan bertukar data.
API
mengungkapkan komponen perangkat lunak dalam hal operasi, input, output,
dan jenis yang mendasarinya, mendefinisikan fungsi yang independen dari
implementasi masing-masing, yang memungkinkan definisi dan implementasi
bervariasi tanpa mengorbankan antarmuka. Sebuah API yang baik membuatnya lebih
mudah untuk mengembangkan program dengan menyediakan semua blok bangunan, yang
kemudian disatukan oleh programmer.
API mungkin
untuk sistem berbasis web, sistem operasi, atau sistem database, dan
menyediakan fasilitas untuk mengembangkan aplikasi untuk sistem yang
menggunakan bahasa pemrograman tertentu. Sebagai contoh, seorang programmer
yang mengembangkan aplikasi untuk Android dapat menggunakan API Android untuk
berinteraksi dengan hardware, seperti kamera depan perangkat berbasis Android.
Selain
mengakses database atau perangkat keras komputer seperti hard
disk drive atau kartu
video , API dapat
meringankan pekerjaan pemrograman GUI komponen. Sebagai contoh, sebuah
API dapat memfasilitasi integrasi fitur baru ke dalam aplikasi yang ada (yang
disebut-"plug-in API"). API juga dapat membantu aplikasi lain yang
berbeda dengan data sharing, yang dapat membantu untuk mengintegrasikan dan
meningkatkan fungsi dari aplikasi.
API adalah
salah satu cara yang paling umum perusahaan teknologi mengintegrasikan dengan
satu sama lain. Mereka yang menyediakan dan menggunakan API dianggap sebagai
anggota dari ekosistem bisnis. [4]
Penggunaan
API dalam bahasa prosedural
Dalam
kebanyakan bahasa prosedural, API menentukan satu set fungsi
atau rutinitas yang
menyelesaikan tugas tertentu, atau diperbolehkan untuk berinteraksi dengan
komponen perangkat lunak tertentu. Spesifikasi ini disajikan dalam format yang
dapat dibaca manusia di buku kertas atau dalam format elektronik seperti eBook
atau sebagai man . Sebagai contoh, API matematika
pada Unix sistem adalah spesifikasi tentang
cara menggunakan fungsi matematika termasuk dalam perpustakaan matematika. Di
antara fungsi-fungsi ini ada fungsi bernama sqrt() , yang
dapat digunakan untuk menghitung akar kuadrat dari angka yang diberikan.
Perintah
Unix man 3 sqrt menyajikan tanda
tangan dari fungsi
sqrt berupa:
RINGKASAN
#
include <math.h>
sqrt ganda (double X);
mengapung sqrtf (float X);
DESKRIPSI
sqrt
menghitung akar kuadrat positif dari argumen. ...
RETURNS
Pada
keberhasilan, akar kuadrat dikembalikan. Jika X adalah nyata dan positif ...
Deskripsi
ini berarti bahwa sqrt() mengembalikan fungsi akar kuadrat
dari angka floating point positif ( single atau double presisi), sebagai nomor floating point lain. Halaman manual juga
menyatakan bahwa program menelepon harus menyertakan math.h file header untuk dapat referensi fungsi hadir di perpustakaan matematika.
Oleh karena
itu API dalam hal ini dapat diartikan sebagai koleksi termasuk
file yang
digunakan oleh program, yang ditulis dalam bahasa C, untuk referensi bahwa
fungsi perpustakaan, dan deskripsi dibaca manusia disediakan oleh halaman
manual .
Demikian
pula, bahasa lain memiliki perpustakaan prosedural; misalnya, Perl memiliki API yang didedikasikan
untuk tugas matematika yang sama dengan built-in dokumentasi yang tersedia,
yang dapat diakses menggunakan perldoc utilitas:
$ Perldoc - f
sqrt
sqrt
EXPR
sqrt
#Return akar kuadrat dari EXPR. Jika
EXPR diabaikan, kembali
akar #square dari $ _. Hanya
bekerja pada operan non-negatif, kecuali
# Anda telah dimuat dalam Math :: Complex modul standar.
API dalam bahasa berorientasi objek
Dalam bentuk
yang paling sederhana, sebuah objek API adalah deskripsi tentang bagaimana benda
bekerja dalam bahasa berorientasi objek yang diberikan - biasanya
dinyatakan sebagai satu set kelas dengan daftar terkait metode
kelas .
Misalnya,
dalam bahasa Jawa , jika kelas Scanner yang akan
digunakan (kelas yang membaca masukan dari pengguna di program berbasis teks),
diperlukan untuk mengimpor java.util.Scanner
perpustakaan, sehingga objek dari jenis Scanner dapat digunakan
dengan menerapkan beberapa metode kelas 'yang:
import
java.util.Scanner;
public class
Uji {
public
static void main (String [] args) {
Sistem
out println ( "Masukkan nama Anda:")..;
Scanner
inputScanner = new Scanner (Sistem di.);
Nama
String = inputScanner nextLine ().;
..
Sistem keluar println ( "Nama Anda adalah" + nama + ".");
inputScanner dekat ().;
}
}
Dalam contoh
di atas, metode nextLine() dan close() merupakan bagian dari API untuk Scanner kelas, dan karenanya dijelaskan dalam dokumentasi
untuk API itu, misalnya:
public String nextLine ()
Kemajuan scanner ini melewati garis saat ini dan
mengembalikan masukan dilewati ...
Pengembalian:
garis yang dilewati
melempar:
NoSuchElementException - jika tidak ada garis ditemukan
IllegalStateException - jika
scanner ini telah ditutup
Secara umum,
dalam berorientasi
objek bahasa, API
biasanya mencakup deskripsi dari sekumpulan kelas definisi, dengan satu set perilaku
yang terkait dengan kelas-kelas. Konsep abstrak ini dikaitkan dengan fungsi
nyata terkena, atau disediakan, oleh kelas yang diimplementasikan dalam hal metode
kelas (atau lebih
umum oleh semua komponen publik maka semua metode umum, tetapi juga mungkin
termasuk setiap entitas internal yang dipublikasikan seperti : bidang,
konstanta, benda bersarang, enum, dll).
API dalam
hal ini dapat dipahami sebagai totalitas semua metode publik terpapar oleh
kelas (biasanya disebut kelas antarmuka ). Ini berarti bahwa API mengatur
metode yang satu berinteraksi dengan / menangani objek berasal dari definisi
kelas.
Lebih umum,
orang dapat melihat API sebagai koleksi semua jenis benda yang bisa
diambil dari definisi kelas, dan perilaku yang terkait mungkin. Sekali lagi:
penggunaan dimediasi oleh metode umum, namun dalam penafsiran ini, metode
dipandang sebagai detail teknis tentang bagaimana perilaku
diimplementasikan.
Misalnya:
kelas yang mewakili Stack hanya dapat mengekspos publik dua
metode push() (untuk menambahkan item baru ke
stack), dan pop() (untuk mengekstrak item terakhir,
idealnya ditempatkan di atas tumpukan).
Dalam hal
ini API dapat diartikan sebagai dua metode pop() dan push() , atau, lebih umum, sebagai ide yang dapat digunakan item jenis Stack yang mengimplementasikan perilaku setumpuk: tumpukan mengekspos
puncaknya untuk menambahkan / menghapus elemen. Penafsiran kedua muncul lebih
tepat dalam semangat orientasi
objek .
Konsep ini
dapat dibawa ke titik di mana antarmuka kelas dalam API tidak memiliki metode
sama sekali, tetapi hanya perilaku yang terkait dengan itu. Misalnya, Java dan Lisp API bahasa termasuk antarmuka bernama Serializable , yang merupakan antarmuka
penanda yang
mengharuskan setiap kelas mengimplementasikannya untuk berperilaku dengan serial fashion. Ini tidak memerlukan
penerapan metode umum, namun lebih membutuhkan setiap kelas yang
mengimplementasikan interface ini harus didasarkan pada representasi yang dapat
disimpan (serial) setiap saat. [A]
Demikian
pula perilaku obyek dalam bersamaan ( multi-berulir ) lingkungan tidak selalu
ditentukan oleh metode khusus, milik interface diimplementasikan, tetapi masih
milik API untuk itu Kelas obyek, dan harus dijelaskan dalam dokumentasi. [ 5]
Dalam
pengertian ini, dalam bahasa berorientasi objek, API mendefinisikan satu set
perilaku objek, mungkin dimediasi oleh seperangkat metode kelas.
Dalam bahasa
seperti, API masih didistribusikan sebagai perpustakaan. Misalnya, perpustakaan
bahasa Jawa termasuk satu set API yang disediakan dalam bentuk JDK yang digunakan oleh pengembang
untuk membangun program Java baru. JDK termasuk dokumentasi API di javadoc notasi.
Kualitas
dokumentasi terkait dengan API sering merupakan faktor penentu keberhasilan
dalam hal kemudahan penggunaan.
Perpustakaan API dan kerangka kerja
API biasanya
terkait dengan perpustakaan
software : API
menjelaskan dan mengatur perilaku yang diharapkan sedangkan
perpustakaan merupakan implementasi aktual dari set aturan. Sebuah API
tunggal dapat memiliki beberapa implementasi (atau tidak, menjadi abstrak)
dalam bentuk perpustakaan yang berbeda yang berbagi antarmuka pemrograman yang
sama.
API juga
dapat terkait dengan kerangka kerja perangkat lunak : kerangka dapat didasarkan pada
beberapa perpustakaan menerapkan beberapa API, tapi tidak seperti penggunaan
normal dari API, akses ke perilaku dibangun ke dalam kerangka kerja
dimediasi dengan memperluas isinya dengan kelas baru dicolokkan ke kerangka itu
sendiri. Selain itu, aliran program keseluruhan kontrol dapat keluar dari
kontrol pemanggil, dan di tangan kerangka melalui inversi
kontrol atau
mekanisme yang serupa. [6] [7]
API dan protokol
API juga
dapat merupakan implementasi dari protokol .
Ketika
sebuah API mengimplementasikan protokol itu dapat didasarkan pada proksi metode untuk pemanggilan jarak jauh
yang di bawahnya bergantung pada protokol komunikasi. Peran API dapat tepat
untuk menyembunyikan detail dari protokol transport. Misalnya: RMI adalah sebuah API yang mengimplementasikan
JRMP protokol atau IIOP sebagai RMI-IIOP .
Protokol
biasanya dibagi antara teknologi yang berbeda (sistem berdasarkan bahasa
pemrograman komputer yang diberikan dalam sistem operasi yang diberikan) dan
biasanya memungkinkan teknologi yang berbeda untuk saling bertukar informasi,
bertindak sebagai tingkat abstraksi / mediasi antara dua lingkungan yang
berbeda. Protokol maka dapat dianggap API terpencil, API lokal
bukannya biasanya khusus untuk teknologi tertentu: maka API untuk bahasa
tertentu tidak dapat digunakan dalam bahasa lain, kecuali fungsi panggilan
dibungkus dengan perpustakaan adaptasi tertentu.
Untuk
mengaktifkan pertukaran informasi antara sistem yang menggunakan teknologi yang
berbeda, ketika sebuah API mengimplementasikan protokol, itu dapat meresepkan
format pesan bahasa-netral: misalnya SOAP menggunakan XML sebagai wadah umum untuk pesan yang
akan dipertukarkan, sama SISA API dapat menggunakan baik XML dan JSON .
Objek pertukaran API dan protokol
Sebuah objek
API dapat meresepkan format pertukaran objek tertentu bahwa program dapat
menggunakan lokal dalam aplikasi, sementara protokol pertukaran objek dapat
menentukan cara untuk mentransfer jenis informasi yang sama dalam pesan yang
dikirim ke sistem remote.
Ketika pesan
dipertukarkan melalui protokol antara dua platform yang berbeda menggunakan
benda-benda di kedua sisi, objek dalam bahasa pemrograman bisa diubah ( marshalled dan unmarshalled [8] ) dalam suatu objek dalam bahasa
terpencil dan berbeda: sehingga, misalnya, program yang ditulis dalam Java memanggil layanan melalui SOAP atau IIOP ditulis dalam C # kedua program menggunakan API untuk remote doa
(masing-masing secara lokal ke mesin mana mereka bekerja) ke (jarak jauh)
pertukaran informasi bahwa mereka berdua mengkonversi dari / ke obyek dalam
memori lokal .
Sebaliknya
jika benda mirip dipertukarkan melalui API lokal ke mesin tunggal objek tersebut
efektif dipertukarkan (atau referensi untuk itu) dalam memori: misalnya melalui memori yang
dialokasikan oleh proses tunggal, atau antara beberapa proses menggunakan memori bersama , sebuah server
aplikasi , atau
teknologi berbagi lainnya seperti ruang
tupel .
Objek Remoting API dan protokol
API objek
Remoting didasarkan pada protokol Remoting, seperti CORBA , yang memungkinkan metode remote
object doa. Panggilan metode, dieksekusi secara lokal pada objek proxy,
memanggil sesuai metode pada objek remote, menggunakan protokol Remoting, dan
memperoleh hasil yang akan digunakan secara lokal sebagai nilai kembali. [9]
Ketika
Remoting di tempat, modifikasi pada objek proxy sesuai dengan modifikasi pada
objek jarak jauh. Ketika hanya transfer objek berlangsung, modifikasi untuk
salinan lokal dari objek tersebut tidak tercermin pada objek asli, kecuali
benda tersebut dikirim kembali ke sistem pengiriman.
Berbagi API dan menggunakan kembali melalui mesin
virtual
Misalnya,
melalui representasi kode byte, program yang ditulis dalam Groovy atau Scala bahasa dapat menggunakan setiap kelas standar Java
dan karenanya setiap API Java. Hal ini dimungkinkan berkat kenyataan baik
Groovy dan Scala memiliki model
objek yang satu
set super yang dari bahasa Jawa; dengan demikian, setiap API terkena melalui
objek Java dapat diakses melalui Groovy atau Scala oleh doa objek setara
diterjemahkan dalam kode byte.
Di sisi
lain, Groovy dan Scala memperkenalkan entitas kelas yang tidak hadir di Jawa, seperti penutupan . Entitas ini tidak dapat native diwakili dalam
bahasa Jawa ( Jawa
8
memperkenalkan konsep ekspresi
lambda ); dengan
demikian, untuk memungkinkan operasi lain, penutupan dirumuskan dalam sebuah
objek Java standar. Dalam hal ini penutupan doa dimediasi oleh
sebuah metode bernama call() , yang selalu hadir dalam suatu
objek penutupan seperti yang terlihat oleh Java, dan di Jawa penutupan tidak
mewakili entitas kelas .
API web
Penggunaan web untuk berbagi konten
Praktek
penerbitan API telah memungkinkan komunitas web untuk membuat arsitektur
terbuka untuk berbagi konten dan data antara masyarakat dan aplikasi. Dengan
cara ini, konten yang dibuat di satu tempat dapat secara dinamis diposting dan
diperbarui di beberapa lokasi di web:
- Foto dapat dibagi dari situs
seperti Flickr dan Photobucket untuk jaringan sosial situs-situs seperti Facebook dan MySpace .
- Konten dapat tertanam, misalnya
menanamkan presentasi dari SlideShare pada LinkedIn
profil.
- Konten dapat secara dinamis
diposting. Berbagi komentar hidup dibuat di Twitter dengan
akun Facebook, misalnya, diaktifkan oleh API mereka.
- Konten video dapat tertanam di
situs dilayani oleh host lain.
- Informasi pengguna dapat dibagi
dari komunitas web untuk aplikasi luar, memberikan fungsi baru untuk komunitas
web dimana data pengguna yang melalui API terbuka. Salah satu contoh
terbaik dari ini adalah platform yang Aplikasi Facebook . Lain adalah Sosial Terbuka Platform. [13]
- Jika konten adalah representasi
langsung dari dunia fisik (misalnya, suhu di lokasi geospasial di bumi)
maka API dapat dianggap sebagai "Programming Lingkungan
Interface" (EPI). EPIs ditandai dengan kemampuan mereka untuk
menyediakan sarana untuk acara sequencing universal yang cukup untuk
memanfaatkan data dunia nyata untuk pengambilan keputusan.
Implementasi
The POSIX standar mendefinisikan API yang
memungkinkan menulis berbagai fungsi komputasi umum dalam sedemikian rupa
sehingga mereka dapat beroperasi pada banyak sistem yang berbeda ( Mac
OS X , dan
berbagai Berkeley Software Distribusi (BSD) mengimplementasikan interface
ini) .Namun, menggunakan ini membutuhkan re-kompilasi untuk setiap platform. Sebuah API
kompatibel, di sisi lain, memungkinkan dikompilasi kode
objek untuk
berfungsi tanpa perubahan pada sistem yang mengimplementasikan API itu.
Hal ini menguntungkan kedua penyedia perangkat lunak (di mana mereka dapat
mendistribusikan perangkat lunak yang ada pada sistem baru tanpa memproduksi
dan → mendistribusikan upgrade) dan pengguna (di mana mereka dapat menginstal
perangkat lunak yang lebih tua pada sistem baru mereka tanpa membeli upgrade),
meskipun ini biasanya membutuhkan bahwa berbagai perpustakaan
software
mengimplementasikan API yang diperlukan juga.
Microsoft telah menunjukkan komitmen yang
kuat untuk API kompatibel mundur, terutama dalam mereka API
Windows (Win32)
perpustakaan, sehingga aplikasi yang lebih tua mungkin berjalan pada versi
terbaru dari Windows menggunakan pengaturan dieksekusi khusus yang disebut
"Compatibility Mode". [14]
Di antara Unix-seperti sistem operasi, ada banyak sistem
operasi terkait tetapi tidak kompatibel berjalan pada platform perangkat keras
yang umum (terutama Intel
80386 sistem yang
kompatibel dengan). Ada beberapa upaya untuk membakukan API sehingga vendor
perangkat lunak dapat mendistribusikan satu aplikasi biner untuk semua sistem
ini; Namun, sampai saat ini, tak satu pun dari telah bertemu dengan banyak
keberhasilan. The Linux
Standard Base mencoba
untuk melakukan hal ini untuk Linux platform yang, sementara banyak
dari BSD Unix, seperti FreeBSD , NetBSD , dan OpenBSD , menerapkan berbagai tingkat
kompatibilitas API untuk kedua kompatibilitas (memungkinkan program yang
ditulis untuk versi untuk berjalan di distribusi yang lebih baru dari sistem)
dan kompatibilitas cross-platform (yang memungkinkan eksekusi kode asing tanpa
mengkompilasi ulang).
Desain API
Beberapa
prinsip yang umum digunakan untuk mengatur proses merancang API. Parnas
mengusulkan konsep menyembunyikan
informasi pada tahun
1972. Prinsip bersembunyi informasi adalah bahwa seseorang dapat membagi
software menjadi modul, yang masing-masing memiliki antarmuka yang ditentukan.
Interface menyembunyikan rincian implementasi dari modul sehingga pengguna
modul tidak perlu memahami kompleksitas dalam modul. Interface ini API, dan
sebagai hasilnya, API harus mengekspos hanya mereka Rincian modul yang klien
harus tahu untuk menggunakan modul secara efektif. Arsitektur Software didedikasikan untuk menciptakan dan memelihara
struktur-yang software tingkat tinggi biasanya meliputi modul. API mencerminkan
antarmuka antara modul. Dengan demikian, arsitektur sistem terkait terkait
dengan API yang mengekspresikan arsitektur itu. Namun, banyak keputusan yang
terlibat dalam menciptakan API tidak arsitektur, seperti konvensi penamaan dan
banyak rincian tentang bagaimana interface yang terstruktur.
Rincian ini
tentang bagaimana interface yang terstruktur, serta arsitektur perangkat lunak,
memiliki dampak signifikan pada kualitas perangkat lunak. Misalnya, Cataldo et
al. menemukan bahwa bugginess berkorelasi dengan logis dan data dependensi
dalam perangkat lunak. [15] Ini berarti bahwa untuk mengurangi
tingkat bug, pengembang perangkat lunak harus hati-hati mempertimbangkan API
dependensi.
Hukum
Conway menyatakan
bahwa struktur sistem pasti mencerminkan struktur organisasi yang
menciptakannya. Hal ini menunjukkan bahwa untuk memahami bagaimana API
dirancang di dunia nyata, kita juga harus memahami struktur organisasi rekayasa
perangkat lunak. Demikian juga, sebuah kelompok API harus struktur itu sendiri
sesuai dengan apa yang dibutuhkan API. Dalam sebuah studi dari 775 insinyur
perangkat lunak Microsoft, Begel et al. ditemukan bahwa selain
mengkoordinasikan mengenai desain API, insinyur perangkat lunak bahkan lebih sering
berkoordinasi mengenai jadwal dan fitur. [16] ini memperkuat pandangan bahwa
organisasi perangkat lunak berkolaborasi secara ekstensif dan bahwa struktur
organisasi adalah penting.
Beberapa
penulis telah menciptakan rekomendasi untuk bagaimana merancang API, seperti Joshua
Bloch [17] dan Michi Henning. [18] Namun, karena salah satu prinsip
desain API adalah bahwa API harus konsisten dengan API lainnya sudah digunakan
di sistem, rincian desain API agak language- dan sistem-dependent.
Kebijakan rilis
Kebijakan
utama untuk merilis API adalah:
- Melindungi informasi tentang
API dari masyarakat umum. Misalnya, Sony
digunakan untuk membuat resminya PlayStation 2 API tersedia hanya untuk lisensi pengembang
PlayStation. Hal ini memungkinkan Sony untuk mengontrol yang menulis
PlayStation 2 game. Hal ini memberikan hak kontrol kualitas perusahaan dan
dapat menyediakan mereka dengan potensi aliran pendapatan lisensi.
- Membuat API tersedia secara
bebas. Misalnya, Microsoft
membuat Microsoft Windows API umum, dan Apel rilis nya API Karbon dan Kakao ,
sehingga perangkat lunak yang dapat ditulis untuk mereka platform .
Sebuah
campuran dari dua perilaku dapat digunakan juga.
Implikasi API publik
API dapat
dikembangkan untuk kelompok terbatas pengguna, atau dapat dirilis ke publik.
Merupakan
faktor penting ketika sebuah API menjadi publik adalah stabilitas antarmuka.
Perubahan oleh pengembang untuk bagian dari itu-misalnya menambahkan parameter
baru untuk fungsi panggilan-bisa istirahat kompatibilitas dengan klien yang
bergantung pada API itu.
Ketika
bagian dari API yang disajikan publik dapat berubah dan dengan demikian tidak
stabil, bagian tersebut dari API tertentu harus secara eksplisit
didokumentasikan sebagai tidak stabil. Misalnya, di Google
jambu
perpustakaan bagian yang dianggap tidak stabil, dan yang mungkin berubah dalam
waktu dekat, ditandai dengan penjelasan
Java @Beta . [19]
API Penghentian
Sebuah API
publik kadang-kadang dapat menyatakan bagian dari dirinya sebagai usang . Hal ini biasanya berarti bahwa
bagian tersebut dari sebuah API harus dipertimbangkan candidated untuk dihapus,
atau diubah dengan cara yang tidak kompatibel ke belakang.
Ketika
mengadopsi pihak ketiga API publik, pengembang harus mempertimbangkan kebijakan
depresiasi yang digunakan oleh produsen API itu; jika pengembang publik
melepaskan solusi berdasarkan API yang menjadi usang, ia / dia mungkin tidak
dapat menjamin layanan yang disediakan.
