PENGERTIAN SESSION LAYER

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.

Dalam pemrograman komputer , sebuah antarmuka pemrograman aplikasi (API) adalah seperangkat rutinitas , protokol, dan alat untuk membangun perangkat lunak dan aplikasi.

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 sering datang dalam bentuk sebuah perpustakaan yang mencakup spesifikasi untuk rutinitas , struktur data , kelas objek , dan variabel. Dalam kasus lain, terutama SOAP dan SISA layanan , API hanyalah sebuah spesifikasi panggilan jarak jauh terkena konsumen API. ^[1]

Sebuah spesifikasi API dapat mengambil banyak bentuk, termasuk Standar Internasional, seperti POSIX , penjual dokumentasi, seperti Microsoft Windows API , atau perpustakaan dari bahasa pemrograman , misalnya Perpustakaan Template Standar di C ++ atau Java API .

API berbeda dari sebuah antarmuka aplikasi biner (ABI) di bahwa API adalah kode sumber berbasis sementara ABI adalah antarmuka biner. Misalnya POSIX adalah sebuah API, sedangkan Linux Standard Base menyediakan ABI. ^{[2] [3]}

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

Beberapa bahasa seperti yang berjalan dalam mesin virtual (misalnya NET bahasa CLI compliant dalam waktu Common Language Run (CLR), dan JVM bahasa compliant di Java Virtual Machine ) dapat berbagi API. Dalam hal ini, mesin virtual memungkinkan interoperabilitas bahasa , dengan abstrak bahasa pemrograman menggunakan perantara kode byte dan yang binding bahasa . Dalam bahasa ini, compiler melakukan kompilasi just-in-time atau kompilasi depan-of-waktu mengubah kode sumber, kemungkinan ditulis dalam beberapa bahasa, menjadi representasi kode byte bahasa-independen.

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

Artikel utama: Web API

API web adalah antarmuka yang didefinisikan melalui interaksi yang terjadi antara perusahaan dan aplikasi yang menggunakan asetnya. Pendekatan API adalah sebuah pendekatan arsitektur yang berkisah menyediakan antarmuka diprogram untuk satu set layanan untuk aplikasi yang berbeda melayani berbagai jenis konsumen. ^[10] Ketika digunakan dalam konteks pengembangan web , API biasanya didefinisikan sebagai satu set Hypertext Transfer Protocol (HTTP) pesan permintaan, bersama dengan definisi struktur pesan respon, yang biasanya dalam Extensible Markup Language ( XML ) atau JavaScript Object Notation ( JSON ) format. Sementara "Web API" secara historis telah hampir identik untuk layanan web , tren terbaru (disebut Web 2.0 ) telah bergerak jauh dari Simple Object Access Protocol ( SOAP layanan berbasis web) dan arsitektur berorientasi layanan (SOA) terhadap lebih langsung representasional Transfer negara (REST) ​​gaya sumber web dan sumber daya arsitektur berorientasi (ROA). ^[11] Bagian dari tren ini terkait dengan Semantic Web gerakan menuju resource Description Framework (RDF), sebuah konsep untuk mempromosikan berbasis web engineering ontologi teknologi . API web memungkinkan kombinasi dari beberapa API ke dalam aplikasi baru yang dikenal sebagai mashup . ^[12]

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.