Translate section 23: Communication

pull/360/head
Roy Ginting 2020-02-10 17:52:48 +07:00
parent 05f2ead9f8
commit 69bce3813b
1 changed files with 119 additions and 87 deletions

View File

@ -1495,78 +1495,94 @@ Klien dapat mencoba mengiriman permintaan lagi di waktu yang akan datang dengan
<p align="center">
<img src="http://i.imgur.com/5KeocQs.jpg"/>
<br/>
<i><a href=http://www.escotal.com/osilayer.html>Source: OSI 7 layer model</a></i>
<i><a href=http://www.escotal.com/osilayer.html>Sumber: Model 7 lapisan OSI</a></i>
</p>
### Hypertext transfer protocol (HTTP)
HTTP is a method for encoding and transporting data between a client and a server. It is a request/response protocol: clients issue requests and servers issue responses with relevant content and completion status info about the request. HTTP is self-contained, allowing requests and responses to flow through many intermediate routers and servers that perform load balancing, caching, encryption, and compression.
HTTP adalah metode pengkodean dan pengiriman data antara klien dan server.
HTTP merupakan protokol permintaan/tanggapan dimana klien mengirimkan permintaan dan server menerbitkan tanggapan dengan konten yang relevan dan informasi status penyelesaian mengenai permintaan klien.
HTTP bersifat mandiri, memungkinkan permintaan dan tanggapan mengalir melewati berbagai perute menengah dan server yang melakukan penyeimbangan beban, persinggahan, enkripsi, dan kompresi.
A basic HTTP request consists of a verb (method) and a resource (endpoint). Below are common HTTP verbs:
Dasar permintaan HTTP terdiri dari kata kerja (metode) dan sumber daya (endpoint).
Berikut adalah kata kerja HTTP yang umum:
| Verb | Description | Idempotent* | Safe | Cacheable |
| Kata kerja | Deskripsi | Idempoten* | Aman | Bisa disinggahkan |
|---|---|---|---|---|
| GET | Reads a resource | Yes | Yes | Yes |
| POST | Creates a resource or trigger a process that handles data | No | No | Yes if response contains freshness info |
| PUT | Creates or replace a resource | Yes | No | No |
| PATCH | Partially updates a resource | No | No | Yes if response contains freshness info |
| DELETE | Deletes a resource | Yes | No | No |
| GET | Membaca sumber daya | Ya | Ya | Ya |
| POST | Menciptakan sumber daya atau memicu proses yang menangani data | Tidak | Tidak | Ya jika tanggapan berisi informasi kesegaran |
| PUT | Menciptakan atau mengganti sumber daya | Ya | Tidak | Tidak |
| PATCH | Memperbarui sebagian sumber daya | Tidak | Tidak | Ya jika tanggapan berisi informasi kesegaran |
| DELETE | Menghapus sumber daya | Ya | Tidak | Tidak |
*Can be called many times without different outcomes.
*Menghasilkan hasil yang sama ketika dipanggil berkali-kali.
HTTP is an application layer protocol relying on lower-level protocols such as **TCP** and **UDP**.
HTTP adalah protokol pada lapisan aplikasi yang bergantung pada protokol lapisan bawah seperti **TCP** dan **UDP**.
#### Source(s) and further reading: HTTP
#### Sumber dan bacaan lanjutan: HTTP
* [What is HTTP?](https://www.nginx.com/resources/glossary/http/)
* [Difference between HTTP and TCP](https://www.quora.com/What-is-the-difference-between-HTTP-protocol-and-TCP-protocol)
* [Difference between PUT and PATCH](https://laracasts.com/discuss/channels/general-discussion/whats-the-differences-between-put-and-patch?page=1)
* [Apakah HTTP itu?](https://www.nginx.com/resources/glossary/http/)
* [Perbedaan antara HTTP dan TCP](https://www.quora.com/What-is-the-difference-between-HTTP-protocol-and-TCP-protocol)
* [Perbedaan antara PUT dan PATCH](https://laracasts.com/discuss/channels/general-discussion/whats-the-differences-between-put-and-patch?page=1)
### Transmission control protocol (TCP)
<p align="center">
<img src="http://i.imgur.com/JdAsdvG.jpg"/>
<br/>
<i><a href=http://www.wildbunny.co.uk/blog/2012/10/09/how-to-make-a-multi-player-game-part-1/>Source: How to make a multiplayer game</a></i>
<i><a href=http://www.wildbunny.co.uk/blog/2012/10/09/how-to-make-a-multi-player-game-part-1/>Sumber: Bagaimana membuat permainan banyak pemain</a></i>
</p>
TCP is a connection-oriented protocol over an [IP network](https://en.wikipedia.org/wiki/Internet_Protocol). Connection is established and terminated using a [handshake](https://en.wikipedia.org/wiki/Handshaking). All packets sent are guaranteed to reach the destination in the original order and without corruption through:
TCP adalah protokol berorientasi koneksi yang melalui [jaringan IP](https://en.wikipedia.org/wiki/Internet_Protocol)
Koneksi dibangun dan diterminasi menggunakan [salam](https://en.wikipedia.org/wiki/Handshaking)
Seluruh paket yang dikirim dijamin akan mencapai tujuan sesuai dengan urutan pengiriman tanpa korupsi melalui:
* Sequence numbers and [checksum fields](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Checksum_computation) for each packet
* [Acknowledgement](https://en.wikipedia.org/wiki/Acknowledgement_(data_networks)) packets and automatic retransmission
* Nomor urut dan [checksum fields](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Checksum_computation) untuk setiap paket
* [Pengakuan](https://en.wikipedia.org/wiki/Acknowledgement_(data_networks)) paket dan pengiriman ulang secara otomatis
If the sender does not receive a correct response, it will resend the packets. If there are multiple timeouts, the connection is dropped. TCP also implements [flow control](https://en.wikipedia.org/wiki/Flow_control_(data)) and [congestion control](https://en.wikipedia.org/wiki/Network_congestion#Congestion_control). These guarantees cause delays and generally result in less efficient transmission than UDP.
Jika pengiriman tidak menerima tanggapan yang benar maka paket akan dikirim ulang.
Jika waktu habis beberapa kali maka koneksi akan batalkan.
TCP juga menjalankan [flow control](https://en.wikipedia.org/wiki/Flow_control_(data)) dan [congestion control](https://en.wikipedia.org/wiki/Network_congestion#Congestion_control).
Jaminan ini menyebabkan jeda dan menghasilkan pengiriman yang kurang efisien dibandingkan UDP.
To ensure high throughput, web servers can keep a large number of TCP connections open, resulting in high memory usage. It can be expensive to have a large number of open connections between web server threads and say, a [memcached](https://memcached.org/) server. [Connection pooling](https://en.wikipedia.org/wiki/Connection_pool) can help in addition to switching to UDP where applicable.
Untuk memastikan lewatan yang tinggi, server web membuka koneksi TCP dalam jumlah yang besar yang berdampak pada penggunaan memori yang tinggi.
Membuka koneksi dalam jumlah yang besar antara ulir server web dengan server lain seperti Memcached memiliki harga yang mahal.
[Connection pooling](https://en.wikipedia.org/wiki/Connection_pool) bisa membantu meringankan biaya koneksi selain berganti ke protokol UDP jika dirasa tepat.
TCP is useful for applications that require high reliability but are less time critical. Some examples include web servers, database info, SMTP, FTP, and SSH.
TCP berguna untuk aplikasi yang memerlukan keandalan tinggi tetapi tidak kritis terhadap waktu.
Beberapa contoh pengguna protokol TCP adalah server web, basis data, SMTP, FTP, dan SSH.
Use TCP over UDP when:
Gunakan TCP daripada UDP ketika:
* You need all of the data to arrive intact
* You want to automatically make a best estimate use of the network throughput
* Kita perlu seluruh data sampai dengan utuh
* Kita ingin secara otomatis menggunakan estimasi terbaik dari lewatan jaringan
### User datagram protocol (UDP)
<p align="center">
<img src="http://i.imgur.com/yzDrJtA.jpg"/>
<br/>
<i><a href=http://www.wildbunny.co.uk/blog/2012/10/09/how-to-make-a-multi-player-game-part-1/>Source: How to make a multiplayer game</a></i>
<i><a href=http://www.wildbunny.co.uk/blog/2012/10/09/how-to-make-a-multi-player-game-part-1/>Sumber: Bagaimana membuat permainan banyak pemain</a></i>
</p>
UDP is connectionless. Datagrams (analogous to packets) are guaranteed only at the datagram level. Datagrams might reach their destination out of order or not at all. UDP does not support congestion control. Without the guarantees that TCP support, UDP is generally more efficient.
UDP adalah protokol tanpa koneksi.
Datagram (sepadan dengan paket) hanya dijamin pada level datagram.
Datagram mungkin mencapai tujuannya secara tidak berurut atau tidak sampai sama sekali.
UDP tidak mendukung kontrol kemacetan.
Tanpa jaminan seperti yang didukung TCP, UDP secara umum lebih efisien.
UDP can broadcast, sending datagrams to all devices on the subnet. This is useful with [DHCP](https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol) because the client has not yet received an IP address, thus preventing a way for TCP to stream without the IP address.
UDP bisa mengirimkan datagram ke seluruh perangkat yang ada di jaringan.
Hal ini berguna pada [DHCP](https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol) karena klien belum memiliki alamat IP sehingga menghalangi TCP untuk bisa bekerja.
UDP is less reliable but works well in real time use cases such as VoIP, video chat, streaming, and realtime multiplayer games.
UDP kuranga dapat diandalkan tetapi bekerja dengan baik untuk kasus penggunaan waktu nyata seperti VoIP, obrolan video, streaming, dan permain banyak pemain waktu nyata.
Use UDP over TCP when:
Gunakan UDP daripada TCP ketika:
* You need the lowest latency
* Late data is worse than loss of data
* You want to implement your own error correction
* Kita membutuhkan latensi terendah
* Data telat lebih parah dibandingkan data hilang
* Kita ingin menerapkan sendiri mekanisme koreksi kesalahan
#### Source(s) and further reading: TCP and UDP
#### Sumber dan bacaan lanjutan: TCP dan UDP
* [Networking for game programming](http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/)
* [Key differences between TCP and UDP protocols](http://www.cyberciti.biz/faq/key-differences-between-tcp-and-udp-protocols/)
@ -1580,21 +1596,24 @@ Use UDP over TCP when:
<p align="center">
<img src="http://i.imgur.com/iF4Mkb5.png"/>
<br/>
<i><a href=http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview>Source: Crack the system design interview</a></i>
<i><a href=http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview>Sumber: Memecahkan wawancara perangcangan sistem</a></i>
</p>
In an RPC, a client causes a procedure to execute on a different address space, usually a remote server. The procedure is coded as if it were a local procedure call, abstracting away the details of how to communicate with the server from the client program. Remote calls are usually slower and less reliable than local calls so it is helpful to distinguish RPC calls from local calls. Popular RPC frameworks include [Protobuf](https://developers.google.com/protocol-buffers/), [Thrift](https://thrift.apache.org/), and [Avro](https://avro.apache.org/docs/current/).
Pada RPC, klien menyebabkan prosedur dieksekusi pada ruang alamat berbeda, biasanya pada server jarak jauh.
Prosedur dikode dengan cara seolah-olah prosedur adalah pemanggilan lokal, menyembunyikan detail cara komunikasi antara klien program dengan server.
Pemanggilan jarak jauh biasanya lebih lambat dan kurang biasa diandalkan dibandingkan dengan pemanggilan lokal sehingga pembedaan antara pemanggilan RCP dan lokal berguna untuk dilakukan.
Kerangka kerja RPC yang popular termasuk di dalamnya adalah [Protobuf](https://developers.google.com/protocol-buffers/), [Thrift](https://thrift.apache.org/), dan [Avro](https://avro.apache.org/docs/current/).
RPC is a request-response protocol:
RPC adalah protokol permintaan-tanggapan:
* **Client program** - Calls the client stub procedure. The parameters are pushed onto the stack like a local procedure call.
* **Client stub procedure** - Marshals (packs) procedure id and arguments into a request message.
* **Client communication module** - OS sends the message from the client to the server.
* **Server communication module** - OS passes the incoming packets to the server stub procedure.
* **Server stub procedure** - Unmarshalls the results, calls the server procedure matching the procedure id and passes the given arguments.
* The server response repeats the steps above in reverse order.
* **Client program** - Memanggil prosedur rintisan klien. Parameter dikirim ke tumpukan seperti pemanggilan prosedur lokal.
* **Client stub procedure** - Menyusun id dan argumen prosedur ke dalam pesan permintaan.
* **Client communication module** - Sistem operasi mengirimkan pesan dari klien ke server.
* **Server communication module** - Sistem operasi menyampaikan paket yang datang ke prosedur rintisan server.
* **Server stub procedure** - Membongkar pesan permintaan dari klien, memanggil prosedur server yang sesuai dengan id dan menyampaikan argumen pemanggilan.
* Tanggapan server mengulangi langkah-langkah di atas dengan urutan terbalik.
Sample RPC calls:
Contoh pemanggilan RPC:
```
GET /someoperation?data=anId
@ -1605,37 +1624,39 @@ POST /anotheroperation
"anotherdata": "another value"
}
```
RPC fokus pada memperlihatkan perilaku.
RPC umumnya digunakan untuk alasan kinerja pada komunikasi internal, karena kita bisa menempa pemanggilan alami sesuai dengan kebutuhan kasus penggunan kita.
RPC is focused on exposing behaviors. RPCs are often used for performance reasons with internal communications, as you can hand-craft native calls to better fit your use cases.
Pilih pustaka alamiah (alias SDK) ketika:
Choose a native library (aka SDK) when:
* Kita mengetahui platform sasaran kita.
* Kita ingin mengontrol cara akses "logik" kita.
* Kita ingin mengendalikan cara kontrol kesalahan terjadi di luar pustaka kita.
* Kinerja dan pengalaman pengguna akhir adalah perhatian utama kita.
* You know your target platform.
* You want to control how your "logic" is accessed.
* You want to control how error control happens off your library.
* Performance and end user experience is your primary concern.
API HTTP yang mengikuti REST cendrung lebih banyakan digunakan untuk API publik.
HTTP APIs following **REST** tend to be used more often for public APIs.
#### Kekurangan: RPC
#### Disadvantage(s): RPC
* RPC clients become tightly coupled to the service implementation.
* A new API must be defined for every new operation or use case.
* It can be difficult to debug RPC.
* You might not be able to leverage existing technologies out of the box. For example, it might require additional effort to ensure [RPC calls are properly cached](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) on caching servers such as [Squid](http://www.squid-cache.org/).
* Klien RPC menjadi lebih terikat pada implementasi layanan.
* API baru perlu didefinisikan untuk setiap operasi atau kasus penggunaan baru.
* Lebih sulit untuk awakutu (debug) RPC.
* Kita mungkin tidak bisa memanfaatkan teknologi yang telah ada secara langsung. Sebagai contoh, usaha tambahakan diperlukan untuk memastikan [pemanggilan RPC disinggahkan secara tepat](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) pada server singgahan seperti [Squid](http://www.squid-cache.org/).
### Representational state transfer (REST)
REST is an architectural style enforcing a client/server model where the client acts on a set of resources managed by the server. The server provides a representation of resources and actions that can either manipulate or get a new representation of resources. All communication must be stateless and cacheable.
REST adalah gaya arsitektur menegakkan model klien/server dimana klien bertindak terhadap sekumpulan sumber daya yang dikelola oleh server.
Server menyediakan penggambaran dari sumber daya dan aksi yang dapat memanipulasi atau menciptakan penggambaran baru dari sumber daya.
Seluruh komunikasi harus nirkeadaan dan dapat disinggahkan.
There are four qualities of a RESTful interface:
Ada 4 kualitas dari antarmuka berbasis REST:
* **Identify resources (URI in HTTP)** - use the same URI regardless of any operation.
* **Change with representations (Verbs in HTTP)** - use verbs, headers, and body.
* **Self-descriptive error message (status response in HTTP)** - Use status codes, don't reinvent the wheel.
* **[HATEOAS](http://restcookbook.com/Basics/hateoas/) (HTML interface for HTTP)** - your web service should be fully accessible in a browser.
* **Identify resources (URI in HTTP)** - Menggunakan URI yang sama terlepas dari operasi apa pun itu.
* **Change with representations (Verbs in HTTP)** - Menggunakan kata kerja, tajuk, dan badan.
* **Self-descriptive error message (status response in HTTP)** - Gunakan kode status, jangan buat ulang sesuatu yang sudah ada.
* **[HATEOAS](http://restcookbook.com/Basics/hateoas/) (HTML interface for HTTP)** - Layanan web kita dapat diakses secara penuh menggunakan peramban.
Sample REST calls:
Contoh pemanggilan REST:
```
GET /someresources/anId
@ -1644,41 +1665,52 @@ PUT /someresources/anId
{"anotherdata": "another value"}
```
REST is focused on exposing data. It minimizes the coupling between client/server and is often used for public HTTP APIs. REST uses a more generic and uniform method of exposing resources through URIs, [representation through headers](https://github.com/for-GET/know-your-http-well/blob/master/headers.md), and actions through verbs such as GET, POST, PUT, DELETE, and PATCH. Being stateless, REST is great for horizontal scaling and partitioning.
REST fokus pada penampakan data.
REST meminimalkan ikatan antara klien/server dan seringkali digunakan untuk API HTTP publik.
REST menggunakan metode yang generik dan seragam untuk penampakan sumber daya melalui URIs, [penggambaran melalui tajuk](https://github.com/for-GET/know-your-http-well/blob/master/headers.md), dan aksi melalui kata kerja seperti GET, POST, PUT, DELETE, dan PATCH.
Karena nirkeadaan, REST sangat bagus untuk penyekalaan horizontal dan pemecahan.
#### Disadvantage(s): REST
#### Kekurangan: REST
* With REST being focused on exposing data, it might not be a good fit if resources are not naturally organized or accessed in a simple hierarchy. For example, returning all updated records from the past hour matching a particular set of events is not easily expressed as a path. With REST, it is likely to be implemented with a combination of URI path, query parameters, and possibly the request body.
* REST typically relies on a few verbs (GET, POST, PUT, DELETE, and PATCH) which sometimes doesn't fit your use case. For example, moving expired documents to the archive folder might not cleanly fit within these verbs.
* Fetching complicated resources with nested hierarchies requires multiple round trips between the client and server to render single views, e.g. fetching content of a blog entry and the comments on that entry. For mobile applications operating in variable network conditions, these multiple roundtrips are highly undesirable.
* Over time, more fields might be added to an API response and older clients will receive all new data fields, even those that they do not need, as a result, it bloats the payload size and leads to larger latencies.
* REST berfokus pada penampakan data.
hal ini mungkin tidak cocok ketika sumber daya tidak teratur secara alamiah atau tidak bisa diakses dalam hierarki sederhana.
Sebagai contoh, pengembalian seluruh catatan yang diperbarui beberapa jam yang lalu yang sesuai dengan sekumpulan peristiwa tertentu tidak bisa dinyatakan dengan mudah menggunakan jalan URI.
Dengan REST, contoh di atas kemungkinan besar dilaksanakan menggunakan kombinasi jalan URI, parameter kueri, dan tubuh permintaan.
* REST umumnya bergantung pada beberapa kata kerja (GET, POST, PUT, DELETE, dan PATCH) yang kadangkala tidak sesuai dengan kasus penggunaan kita.
Sebagai contoh, memindahkan dokumen kedaluarsa ke folder arsip mungkin tidak pas sepenuhnya menggunakan kata kerja tersebut.
* Pengambilan sumber daya rumit dengan hierarki bersarang memerlukan beberapa perjalanan bolak-balik antara klien dan server.
Contohnya mengambil isi dari butir blog dan komentar yang akan ditampilkan dalam satu halaman.
Untuk aplikasi ponsel yang beroperasi diberbagai keadaan jaringan, kebutuhan beberapa perjalanan bolak-balik sangat tidak dinginkan.
* Seiring waktu, ekstra bagian kemungkinan ditambahkan ke dalam tanggapan API.
Klien lama akan menerima seluruh bagian data baru, bahkan klien yang tidak memerlukannya.
Hal ini berdampak pada membesarnya ukuran muatan dan membesarnya latensi.
### RPC and REST calls comparison
### Perbandingan pemanggilan RPC dan REST
| Operation | RPC | REST |
| Operasi | RPC | REST |
|---|---|---|
| Signup | **POST** /signup | **POST** /persons |
| Resign | **POST** /resign<br/>{<br/>"personid": "1234"<br/>} | **DELETE** /persons/1234 |
| Read a person | **GET** /readPerson?personid=1234 | **GET** /persons/1234 |
| Read a persons items list | **GET** /readUsersItemsList?personid=1234 | **GET** /persons/1234/items |
| Add an item to a persons items | **POST** /addItemToUsersItemsList<br/>{<br/>"personid": "1234";<br/>"itemid": "456"<br/>} | **POST** /persons/1234/items<br/>{<br/>"itemid": "456"<br/>} |
| Update an item | **POST** /modifyItem<br/>{<br/>"itemid": "456";<br/>"key": "value"<br/>} | **PUT** /items/456<br/>{<br/>"key": "value"<br/>} |
| Delete an item | **POST** /removeItem<br/>{<br/>"itemid": "456"<br/>} | **DELETE** /items/456 |
| Pendaftaran | **POST** /signup | **POST** /persons |
| Pengunduran diri | **POST** /resign<br/>{<br/>"personid": "1234"<br/>} | **DELETE** /persons/1234 |
| Pengambilan info diri | **GET** /readPerson?personid=1234 | **GET** /persons/1234 |
| Pengambilan daftar butir seseorang | **GET** /readUsersItemsList?personid=1234 | **GET** /persons/1234/items |
| Penambahan butir baru ke butir sesorang | **POST** /addItemToUsersItemsList<br/>{<br/>"personid": "1234";<br/>"itemid": "456"<br/>} | **POST** /persons/1234/items<br/>{<br/>"itemid": "456"<br/>} |
| Penambahan butir | **POST** /modifyItem<br/>{<br/>"itemid": "456";<br/>"key": "value"<br/>} | **PUT** /items/456<br/>{<br/>"key": "value"<br/>} |
| Penghapusan butir | **POST** /removeItem<br/>{<br/>"itemid": "456"<br/>} | **DELETE** /items/456 |
<p align="center">
<i><a href=https://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/>Source: Do you really know why you prefer REST over RPC</a></i>
<i><a href=https://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/>Sumber: Apakah Anda benar-benar tahu mengapa anda memilih REST dibandingkan RPC</a></i>
</p>
#### Source(s) and further reading: REST and RPC
#### Sumber dan bacaan lanjutan: REST dan RPC
* [Do you really know why you prefer REST over RPC](https://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/)
* [When are RPC-ish approaches more appropriate than REST?](http://programmers.stackexchange.com/a/181186)
* [Apakah Anda benar-benar tahu mengapa anda memilih REST dibandingkan RPC](https://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/)
* [Kapan pendekatan ke-RPC-an lebih cocok dibandingkan dengan REST?](http://programmers.stackexchange.com/a/181186)
* [REST vs JSON-RPC](http://stackoverflow.com/questions/15056878/rest-vs-json-rpc)
* [Debunking the myths of RPC and REST](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/)
* [What are the drawbacks of using REST](https://www.quora.com/What-are-the-drawbacks-of-using-RESTful-APIs)
* [Crack the system design interview](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview)
* [Menyanggah mitos RPC dan REST](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/)
* [Apakah kekurangan penggunan REST](https://www.quora.com/What-are-the-drawbacks-of-using-RESTful-APIs)
* [Memecahkan wawancara perancangan sistem](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview)
* [Thrift](https://code.facebook.com/posts/1468950976659943/)
* [Why REST for internal use and not RPC](http://arstechnica.com/civis/viewtopic.php?t=1190508)
* [Kenapa REST untuk penggunaan internal dan bukan RPC](http://arstechnica.com/civis/viewtopic.php?t=1190508)
## Security