Catatan Kuliah

04_RPC_Fundamentals_API

16 menit baca

Materi ini membahas API dan Remote Procedure Call (RPC) sebagai fondasi komunikasi antar proses pada aplikasi terdistribusi — bagaimana satu layanan bisa “memanggil” layanan lain lewat jaringan, format data apa yang dipertukarkan, dan bagaimana keamanan (autentikasi) diterapkan pada komunikasi tersebut. Topik ini menjadi dasar sebelum masuk ke pembahasan GraphQL, Apache Thrift, dan Protocol Buffers/gRPC di materi berikutnya.

Application Programming Interface (API)

API mendefinisikan bagaimana sebuah software dapat digunakan oleh software lain. Ada dua level API yang perlu dibedakan:

  • API untuk library: berisi daftar fungsi dan kelas yang disediakan agar dipanggil dalam proses yang sama, misalnya Java SDK API, Linux Kernel API, atau Socket API.
  • Network API: disediakan oleh sebuah software service agar dipanggil dari proses/mesin lain lewat jaringan — inilah yang disebut RPC API.

Network API dapat diimplementasikan dengan berbagai format/standar, antara lain:

  • Sun (ONC) RPC
  • Java RMI
  • CORBA (sudah obsolete)
  • REST
  • SOAP
  • Apache Thrift
  • Protocol Buffers
  • GraphQL

Karena network API diakses lewat jaringan (berpotensi oleh pihak luar), desainnya wajib memperhatikan penanganan authentication, authorization, dan confidentiality — bukan sekadar mendefinisikan fungsi apa saja yang tersedia.

Web-based vs Non-Web-based, Ingress vs Internal

Dua sudut pandang untuk mengklasifikasikan API:

  • Web-based vs Non-web-based: apakah API dibangun di atas protokol HTTP/web (seperti REST) atau tidak (seperti RPC biner murni).
  • Ingress vs Internal:
    • Ingress API: interaksi antara komponen/sistem dengan pihak eksternal. Pertukarannya umumnya lewat internet sehingga memiliki high latency. Satu call ingress tunggal dari luar bisa saja memicu beberapa interaksi internal di belakang layar sebelum hasil akhirnya dikembalikan ke pemanggil.
    • Internal API: interaksi antar komponen di dalam sistem/organisasi sendiri.

Ilustrasi pada slide menggambarkan satu aktor eksternal (Barista) yang melakukan satu request ingress (“Distributes coffee requests”), namun di baliknya diteruskan ke beberapa service internal (Hot Beverage Barista, Cold Beverage Barista) yang masing-masing memanggil service yang lebih granular lagi (Espresso, Milk, Ice):

Hal yang Perlu Diperhatikan saat Mendesain API

Beberapa aspek desain yang wajib dipertimbangkan sebelum menentukan bentuk API:

Format Data: Teks vs Binary

  • Teks (contoh: JSON, XML): human-readable, mudah di-debug, tapi lebih verbose sehingga menambah overhead ukuran pesan.
  • Binary (contoh: Protocol Buffers, Thrift): lebih ringkas dan efisien secara ukuran/pemrosesan, tapi tidak bisa dibaca langsung oleh manusia.

Gaya Arsitektur (Architecture Style)

Tiga gaya utama yang disebutkan: resource oriented (REST), RPC (command oriented), dan GraphQL. Perbandingan singkatnya:

AspekResource-Oriented (REST)RPC (Command-Oriented)GraphQL
Unit dasarResource/objek data pada sistem (mis. /accounts/12345)Aksi/prosedur yang dipanggil (mis. createMessage)Query ke graph data, client menentukan field yang dibutuhkan
OperasiDipetakan ke HTTP method standar (GET/POST/PUT/DELETE)Nama fungsi bebas sesuai domain aksiSatu endpoint, operasi dibedakan lewat query/mutation
Cocok untukManipulasi data CRUD yang natural dipetakan sebagai resourceAksi yang sulit direpresentasikan sebagai resource (mis. calculateTotal), atau saat perlu kontrak fungsi yang eksplisitKebutuhan fleksibilitas field & menghindari over-/under-fetching
OverheadSedang (bergantung pada HTTP + format teks)Bisa sangat rendah jika berbasis biner (mis. Thrift/gRPC)Bergantung implementasi, umumnya di atas HTTP

Catatan: pembahasan detail GraphQL, Apache Thrift, dan Protocol Buffers (gRPC) ada di materi terpisah — di sini hanya disinggung sebagai pembanding gaya arsitektur.

Command-Oriented vs Resource-Oriented

Sebagai pelengkap tabel di atas: pada gaya command-oriented, API dimodelkan sebagai pemanggilan aksi/perintah langsung (mirip memanggil fungsi biasa), sedangkan pada gaya resource-oriented, API dimodelkan sebagai representasi state dari sebuah resource yang dimanipulasi lewat verb standar (GET/PUT/POST/DELETE).

Granularitas dan Volume Komunikasi

  • Granularitas: seberapa besar/kecil unit operasi yang diekspos oleh API. Call yang terlalu fine-grained (kecil-kecil) memerlukan banyak round-trip; call yang terlalu coarse-grained (besar) bisa mengembalikan data yang tidak semuanya dibutuhkan client.
  • Volume: seberapa besar volume data yang dipertukarkan per request, yang ikut memengaruhi pilihan format data (teks vs binary) dan strategi transport.

High Message Rate, Low Overhead, dan Streaming

  • High message rates, low overhead: pada skenario dengan frekuensi pertukaran pesan yang sangat tinggi (misalnya komunikasi antar microservice internal atau data real-time), overhead per pesan — header HTTP, parsing teks JSON/XML — menjadi signifikan secara akumulatif, sehingga dibutuhkan format/protokol yang lebih ringkas (mendorong lahirnya format biner seperti Thrift/Protocol Buffers).
  • Streaming: kebutuhan mengirim/menerima data secara berkelanjutan (bukan satu request lalu satu response tunggal). Pola request-response klasik REST/HTTP kurang natural untuk kasus ini, sehingga menjadi salah satu pendorong desain protokol seperti gRPC yang mendukung streaming secara native.

HTTP sebagai Basis REST API

HTTP Methods dan Idempotence

MethodFungsiIdempotent?
GETRequest/membaca dataYa
POSTMengirim (post) data baru ke serverTidak
PUTMembuat atau menggantikan dokumen/entityYa
DELETEMenghapus dokumen/entityYa
HEADSerupa GET, tapi hanya mengembalikan headers (tanpa body)Ya
PATCHMengubah sebagian data pada dokumen/entityTidak (secara default)

Idempotence: sebuah request bersifat idempotent jika request tersebut dapat diulang berkali-kali tanpa mengubah hasil akhir dibanding hanya dijalankan sekali. HTTP mengatur bahwa semua method selain POST bersifat idempotent. Ini penting karena HTTP proxy/server dapat mengulang request PUT dan DELETE (misalnya saat retry akibat timeout), sehingga implementasi server harus bisa menangani pengulangan tersebut tanpa efek samping yang tidak diinginkan.

Contoh response status code yang umum: 200 OK (sukses), 301 Moved Permanently (redirect ke URL lain), 403 Forbidden (tidak ada izin), 404 Not Found (URL tidak valid), 500 Internal Server Error.

Contoh Request-Response REST

GET /accounts/12345 HTTP/1.1
Host: bank.example.com
Accept: application/vnd.acme.account+json

HTTP/1.1 200 OK
Content-type: application/vnd.acme.account+json
Content-Length: ...

{
  "account_number": 12345,
  "balance": {
    "currency": "usd",
    "value": 100.00
  },
  "links": {
    "deposit": "/accounts/12345/deposit",
    "withdraw": "/accounts/12345/withdraw",
    "transfer": "/accounts/12345/transfer",
    "close": "/accounts/12345/close"
  }
}

Perhatikan field links pada response di atas: setiap resource menyertakan tautan ke aksi-aksi lanjutan yang tersedia (deposit, withdraw, transfer, close). Pola ini yang dikenal secara umum sebagai HATEOAS (Hypermedia as the Engine of Application State) — client tidak perlu hardcode semua endpoint, cukup mengikuti link yang disediakan oleh server dari resource yang sudah diakses.

Idempotence dalam Praktik: Contoh Elasticsearch

Untuk membuat dokumen di Elasticsearch, ada dua kemungkinan:

PUT /my-index/_doc/2345
{"title": "My Great Article", "txt": "Hi everyone. I'm here to write about…"}

POST /my-index/_doc
{"title": "My Great Article", "txt": "Hi everyone. I'm here to write about…"}
  • Versi PUT (dengan ID eksplisit 2345) bersifat idempotent — jika diulang, dokumen dengan ID yang sama akan ditimpa (overwrite), bukan diduplikasi.
  • Versi POST (tanpa ID, server yang generate ID) tidak idempotent — jika request ini diulang (misalnya karena retry jaringan), bisa membuat dokumen duplikat.

Semantik REST Harus Sesuai Aturan HTTP

Contoh kasus pada aplikasi social media: apakah desain endpoint berikut sudah benar untuk menghapus post sosmed terakhir?

DELETE /user/[user-id]/feed/posts/latest

Desain ini bermasalah, karena HTTP DELETE seharusnya idempotent, sedangkan mengulang perintah di atas (misalnya akibat retry) dapat mengakibatkan lebih dari satu post terhapus — setiap kali dipanggil ulang, “post terakhir” yang tersisa akan ikut terhapus.

Solusi: rujuk resource secara eksplisit lewat ID-nya, bukan lewat kata kunci relatif seperti “latest”:

DELETE /user/[user-id]/feed/post/[post-id]

Input dan Output REST API

Request Inputs:

  • Method: GET untuk pembacaan data, POST/PUT/DELETE untuk operasi edit.
  • Path: mengidentifikasikan jenis request sekaligus bisa berperan sebagai parameter, contoh GET /tweets/kistijantoro.
  • Query parameter setelah main URL, contoh GET /search?startDate=2022-08-08&search=programming+language&api_key=....
  • Headers: cookies, custom headers.
  • Body: umumnya form-encoded atau JSON.

Response Outputs:

  • Status code: 200, 403, 404, 422, dst.
  • Headers dan Body (umumnya JSON) — perlu hati-hati dengan penggunaan custom headers.
  • Umumnya API memerlukan API key atau access token untuk keperluan authentication & authorization.

REST API Design Style

Prinsip dasar desain REST: paths merepresentasikan “resources” — yaitu data atau objek pada sistem. Operasi terhadapnya dipetakan lewat HTTP method:

  • GET → membaca data
  • PUT/POST → membuat atau mengubah data
  • DELETE → menghapus data

Merepresentasikan sembarang aksi (bukan sekadar data) ke dalam gaya REST bisa jadi tricky. Umumnya, aksi tersebut dikonversi menjadi semacam “event resource”. Contoh evolusi desain untuk aksi “membuat pesan baru di inbox”:

  • Cara yang berjalan tapi tidak RESTful: POST /inbox/createMessage (menaruh nama fungsi di path, mirip gaya RPC)
  • Alternatif yang lebih RESTful: POST /inbox/message (message diperlakukan sebagai resource/koleksi)
  • Desain yang lebih baik lagi: PUT /inbox/message/[uuid] (resource dengan identitas eksplisit, sehingga otomatis idempotent)

Mengapa REST/HTTP Banyak Dipakai — Kelebihan dan Kekurangan

Kelebihan menggunakan HTTP (REST)Kekurangan/Kerugian
Enkripsi (TLS/HTTPS) sudah tersedia secara built-inMewarisi kompleksitas HTTP yang sebenarnya tidak selalu diperlukan
Kompresi sudah didukung banyak library/serverFormat human-readable (JSON/XML) menambah overhead ukuran pesan
Hampir setiap bahasa pemrograman punya HTTP libraryPerlu memikirkan ulang desain API agar sesuai model REST (memetakan aksi ke resource bisa sulit)
Banyak server framework siap pakai yang sudah menangani enkripsi, kompresi, database pooling, queueing (Tomcat, Node.js, Django, Flask, FastAPI)—
Web proxy dan cache bisa langsung dimanfaatkan—
HTTP response code cukup generic untuk dipakai ulang di berbagai service—

Contoh REST API publik yang bisa dipelajari dari slide: Twitter REST API, Elasticsearch REST API, Oracle Fusion Cloud Financials REST API, dan Discourse forum public API (dengan contoh output JSON yang bisa langsung dilihat di browser, mis. https://meta.discourse.org/categories.json).

Format Network API yang Lebih Efisien (Sekilas)

Apache Thrift dan Protocol Buffers adalah standar alternatif untuk network API yang tidak dibangun di atas HTTP. Karakteristiknya:

  • Message lebih space-efficient, tapi tidak human-readable.
  • Tanpa overhead HTTP, sehingga pemrosesan di kedua sisi (client & server) lebih ringan.
  • Kita cukup menspesifikasikan daftar fungsi API, lalu tools akan membangkitkan library untuk bahasa pemrograman yang diinginkan — setiap API call dibungkus sebagai pemanggilan fungsi biasa, tanpa perlu menyentuh detail API di level network.

Meskipun lebih efisien, karena kompleksitas ukuran pesan bukan concern utama kebanyakan aplikasi, REST tetap lebih umum digunakan di lapangan. (Detail Thrift dan Protocol Buffers/gRPC dibahas pada materi terpisah.)

Serialisasi Data: JSON dan XML

Memori komputer pada dasarnya adalah array besar, dan program/database menggunakan reference untuk mengorganisasi data menjadi struktur kompleks. Namun, data file adalah array of bytes, dan message yang dikirim lewat jaringan adalah stream serial bytes. Serialisasi adalah proses mengkonversi objek data (dengan struktur ber-reference) menjadi sequence of bytes yang bisa disimpan/dikirim, lalu direkonstruksi kembali di sisi penerima.

JSON (JavaScript Object Notation)

Format data yang dipakai sebagian besar REST API saat ini. Mendukung nesting, dan spasi diabaikan kecuali di dalam tanda kutip. Komponen dasarnya:

  • [ ] untuk list berurut — item dipisahkan koma, dan item bisa berupa nilai JSON apa pun.
  • { } untuk dictionary/object tidak berurut — berisi pasangan key: value dipisahkan koma; key harus berupa string, value bisa berupa JSON apa pun.
  • Tipe nilai dasar: numbers, true/false, null, dan strings dalam tanda kutip ganda "...".
[
  {
    "name": "Amir",
    "age": 21,
    "cars": ["Ford", "Toyota", "Nissan"]
  },
  {
    "name": "Badu",
    "age": 30,
    "hometown": "Bandung"
  }
]

XML (eXtensible Markup Language)

Mendahului JSON, namun saat ini jarang dipakai karena dianggap lebih kompleks dibanding JSON. HTML sendiri sebenarnya adalah dokumen XML untuk web page. Komponen dasarnya:

  • Text
  • Tag: <tagname>...</tagname>, memiliki nama dan berisi XML lain di dalamnya. Start tag punya pasangan end tag, kecuali tag tanpa isi.
  • Atribut: <Tag attr="value" ...>
<people>
  <person name="Amir" age="21">
    <cars>
      <car>Ford</car>
      <car>Toyota</car>
      <car>Nissan</car>
    </cars>
  </person>
  <person name="Badu" age="30">
    <hometown city="Bandung"/>
  </person>
</people>

Pada level byte, dengan encoding UTF-8/ASCII, 1 karakter = 1 byte — sehingga file XML/JSON di atas kabel jaringan pada dasarnya hanyalah deretan byte teks biasa (dapat dilihat langsung lewat tool seperti hexdump -C).

Reference Membuat Serialisasi Tidak Trivial

Karena data dalam memori memakai reference, serialisasi memunculkan pertanyaan yang tidak trivial:

  • Jika sebuah objek di-reference berkali-kali, apakah representasinya harus diulang setiap kali dipakai?
  • Bagaimana penanganan circular reference (dua objek saling mereferensikan satu sama lain)?

Solusi umum: serialisasi dengan reference berupa ID, bukan menyalin ulang seluruh objek. Contoh: data hometown disimpan terpisah dengan hometown_id sebagai kunci, lalu setiap person cukup menyimpan hometown_id sebagai referensi:

{
  "hometowns": [
    { "hometown_id": 1, "city": "Evanston", "province": "Illinois", "population": 74106 },
    { "hometown_id": 2, "city": "Chicago", "province": "Illinois", "population": 2705994 }
  ],
  "people": [
    { "name": "Jess", "hometown_id": 1 },
    { "name": "Jonah", "hometown_id": 1 }
  ]
}

Contoh lain untuk circular reference (setiap orang punya best_friend_id yang saling melingkar):

[
  { "person_id": 1, "name": "Jess", "best_friend_id": 2 },
  { "person_id": 2, "name": "Tom",  "best_friend_id": 3 },
  { "person_id": 3, "name": "Kate", "best_friend_id": 1 }
]

Kelemahan pendekatan ini: memerlukan lebih dari satu pass terhadap data — producer harus menemukan dan menyimpan seluruh objek yang direferensikan sebelum mengirim pesan, dan consumer harus membaca lebih dulu sebelum bisa menemukan data yang dirujuk oleh sebuah ID referensi.

Autentikasi pada API

Autentikasi Berbasis HTML/Form (Cookie & Session)

Pada web page berbasis HTML, alur autentikasi umumnya:

  1. Login screen ditampilkan ke user.
  2. User memasukkan login & password, dikirim ke server.
  3. Server memverifikasi password; jika benar, server mengembalikan cookie berisi session ID.
  4. Browser menyimpan cookie tersebut.
  5. Semua request berikutnya otomatis menyertakan cookie ini; server memverifikasi dan mengidentifikasi user dari situ.
  6. User bisa logout untuk menghapus cookie saat ini; jika dilakukan eksplisit, server dapat menghapus session ID tersebut. Umumnya session ID juga punya expiry time agar otomatis dibersihkan.

Cookie autentikasi sebaiknya di-setup dengan atribut:

  • Secure: hanya dikirim lewat HTTPS.
  • HTTPOnly: tidak bisa diakses lewat JavaScript.
  • SameSite: memastikan cookie hanya dikirim ke server asal yang sama.

Potensi masalah keamanan terkait cookie: XSS (Cross-Site Scripting) dan CSRF (Cross-Site Request Forgery).

Session ID yang tersimpan di cookie bisa berupa dua bentuk:

  • Random unique ID: server menyimpan pemetaan dari ID ke informasi user lainnya. Konsekuensinya, setiap akses memerlukan query ke database/persistent storage — berpotensi menjadi masalah skalabilitas.
  • Rich token: menyematkan informasi tambahan langsung di dalam cookie (mis. user id, expiry, permission), sehingga menghindari akses database berulang. Risikonya, token jenis ini berpotensi dipalsukan jika tidak diamankan. Solusinya: token di-sign, dan bisa juga di-encrypt.
  • Proses signing token dapat dilakukan terpisah dari aplikasi utama dan dipakai bersama oleh banyak service — inilah dasar dari SSO (Single Sign-On).

Autentikasi RESTful — OAuth 2.0

OAuth (khususnya OAuth v2) adalah standar umum untuk autentikasi pada API, terutama REST API. OAuth sebenarnya adalah standar authorization, dan menggunakan konsep scope untuk mendefinisikan cakupan akses yang dimiliki user. OpenID Connect adalah salah satu implementasi populer di atas OAuth (menambahkan lapisan identitas/autentikasi).

Alur dasar OAuth secara umum (lihat diagram di bawah):

  1. Akses tanpa autentikasi di-redirect ke pihak authorizer.
  2. User melakukan review & login di sisi authorizer, lalu dikembalikan dengan auth token.
  3. Akses berikutnya menggunakan token tersebut, dan server mengembalikan response yang sudah terautentikasi.

Contoh flow konkret dengan login page (authorization code flow):

GET https://myservice.com/login
    Return a page with a form to initiate the login with authorizer.com

Follow the flow in the external authorize until login, with something like:

POST https://authorizer.com/authorize
  grant_type=authorization_code
  redirect_uri=https://myservice.com/redirect
  user=myuser
  password=mypassword
    Return 302 Found to https://myservice.com/redirect?code=XXXXX

GET https://myservice.com/redirect?code=XXXXX
-> Login into the system and set proper cookie,
   return 302 to https://myservice.com

Contoh flow lain dengan client credentials (tanpa interaksi user, cocok untuk komunikasi server-ke-server):

POST /token HTTP/1.1
  grant_type=authorization_code
  &client_id=XXXX
  &client_secret=YYYY
    Returns a JSON body with
    {
      "access_token": "ZZZZ",
      "token_type": "bearer",
      "expires_in": 86400
    }

Make new requests setting the header
Authorization: "Bearer ZZZZ"

JWT (JSON Web Token) — Self-Encoded Token

Token yang dikembalikan dari server eksternal dapat berisi informasi tambahan yang di-self-encode langsung ke dalam tokennya sendiri — format standarnya adalah JWT. JWT terdiri dari tiga elemen:

  • Header: berisi informasi bagaimana token di-encode (algoritma & tipe token).
  • Payload: body/isi token. Beberapa field disebut sebagai claim dan sudah menjadi standar, misalnya iss (issuer) dan exp (expiry time, dalam format Unix Epoch).
  • Signature: untuk memverifikasi bahwa token memang berasal dari sumber yang sah (tidak dipalsukan/diubah).

Contoh JWT yang di-encode (dipisahkan titik . menjadi header, payload, signature) beserta hasil decode-nya:

Signature pada contoh di atas dihitung dengan:

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

Client umumnya mengirimkan token ini ke resource server lewat header:

Authorization: Bearer <token>

Alur lengkapnya: (1) Application/Client meminta token ke Authorization Server, (2) Authorization Server mengembalikan token, (3) Client memakai token tersebut untuk mengakses Resource Server (API sebenarnya):

Karena JWT bersifat self-encoded (semua informasi ada di dalam token), ukurannya bisa membesar seiring bertambahnya claim — ini bisa menjadi masalah jika ukuran token menjadi terlalu besar (misalnya lebih dari 8 KB), karena umumnya token dikirim berulang-ulang di header pada setiap request.

RPC: Pengantar dan Evolusi

RPC (Remote Procedure Call) adalah mekanisme IPC (Interprocess Communication) yang memungkinkan sebuah proses memanggil prosedur/fungsi yang dijalankan pada proses lain (bisa pada mesin yang berbeda), seolah-olah pemanggilan tersebut adalah pemanggilan fungsi lokal biasa.

Evolusi historis RPC dan teknologi network API terkait:

TahunPerkembangan
1981Birrell and Nelson mengimplementasikan RPC pertama di Xerox, dilanjutkan dengan RPC di Unix (Sun RPC)
1990-anParadigma Object-Oriented mendorong lahirnya RMI (Java) dan CORBA
1998SOAP — XML-RPC
2000REST
2005JSON-RPC
2007Apache Thrift
2015OpenAPI/RESTful API, gRPC, GraphQL

Dari evolusi ini terlihat bahwa RPC dan REST sebenarnya adalah dua gaya arsitektur API yang berbeda filosofi, bukan satu berevolusi menggantikan yang lain secara linear: REST mengarah ke pemodelan berbasis resource (cocok untuk API publik/ingress yang butuh keterbacaan, kompatibilitas luas, dan caching lewat infrastruktur web), sedangkan RPC (dan turunannya seperti Thrift/gRPC) mengarah ke pemodelan berbasis command/fungsi dengan kontrak yang eksplisit — lebih cocok untuk komunikasi internal antar service dengan kebutuhan high message rate, low overhead, dan dukungan streaming, seperti yang sudah dibahas pada bagian “Hal yang Perlu Diperhatikan” di atas.

Pembahasan mendalam mengenai GraphQL, Apache Thrift, dan Protocol Buffers (gRPC) — termasuk arsitektur, definisi skema, dan contoh implementasinya — dilanjutkan pada materi terpisah.

Flashcard

flashcards Apa perbedaan API ingress dan API internal? :: Ingress adalah interaksi antara komponen/sistem dengan pihak eksternal, umumnya lewat internet dan berlatensi tinggi; satu call ingress bisa memicu banyak interaksi internal di baliknya. API internal adalah interaksi antar komponen dalam sistem/organisasi sendiri. Mengapa endpoint DELETE /user/[user-id]/feed/posts/latest bermasalah secara semantik REST, dan apa solusinya? :: HTTP DELETE seharusnya idempotent, tapi endpoint berbasis “latest” tidak idempotent — mengulang request bisa menghapus lebih dari satu post. Solusinya, rujuk resource lewat ID eksplisit: DELETE /user/[user-id]/feed/post/[post-id]. Pada contoh Elasticsearch, mengapa PUT /my-index/_doc/2345 idempotent sedangkan POST /my-index/_doc tidak? :: PUT menyertakan ID dokumen eksplisit sehingga jika diulang hanya menimpa (overwrite) dokumen yang sama; POST membiarkan server men-generate ID baru sehingga jika diulang bisa membuat dokumen duplikat. Sebutkan tiga komponen JWT dan fungsinya masing-masing. :: Header (informasi cara token di-encode, mis. algoritma), Payload (isi/claim token, mis. issuer iss dan expiry exp), dan Signature (untuk memverifikasi token benar berasal dari sumber sah dan tidak dipalsukan). Apa perbedaan session ID berupa random unique ID vs rich token, dan trade-off masing-masing? :: Random unique ID: server menyimpan pemetaan id ke data user, tapi setiap akses perlu query database (potensi masalah skalabilitas). Rich token: informasi user disematkan langsung di token sehingga tidak perlu akses database, tapi berpotensi dipalsukan sehingga harus di-sign (dan bisa dienkripsi). Kapan gaya RPC/format biner (Thrift, Protocol Buffers) lebih cocok dipakai dibanding REST berbasis HTTP/JSON? :: Ketika dibutuhkan message rate yang sangat tinggi dengan overhead serendah mungkin (banyak komunikasi internal antar service), volume data besar yang perlu efisiensi ukuran pesan, atau kebutuhan streaming data berkelanjutan yang kurang natural pada model request-response REST klasik. Apa tantangan utama serialisasi data terkait reference, dan bagaimana solusi umumnya? :: Tantangannya adalah objek yang direferensikan berkali-kali (apakah representasinya diulang) dan circular reference antar objek. Solusi umum: menyimpan referensi berupa ID (bukan menyalin ulang objek), meski ini memerlukan lebih dari satu pass — producer harus mengumpulkan semua objek referensi dulu, dan consumer harus membaca lebih dulu sebelum menemukan data yang dirujuk. Sebutkan alur dasar OAuth 2.0 secara umum dalam tiga langkah. :: (1) Akses tanpa autentikasi di-redirect ke authorization server; (2) user login/review di authorization server dan menerima auth token; (3) client mengakses resource server menggunakan token tersebut dan menerima response yang sudah terautentikasi. Sebutkan tiga kelebihan utama menggunakan HTTP sebagai basis REST API menurut materi. :: HTTP sudah menyediakan enkripsi (TLS) dan kompresi bawaan, hampir semua bahasa pemrograman punya HTTP library, serta banyak server framework siap pakai (Tomcat, Node.js, Django, Flask, FastAPI) yang sudah menangani enkripsi/kompresi/pooling/queueing, ditambah web proxy & cache yang bisa langsung dimanfaatkan.

Tampilan Grafik

Tautan Balik