Prinsip Desain RESTful

Di sini, saya akan menjelaskan sekumpulan prinsip desain RESTful yang harus dipatuhi saat membuat RESTful service.

Mari kita mulai dengan dasar-dasarnya. Apa itu REST?

REST = REpresentational State Transfer. REST adalah gaya arsitektur untuk perangkat lunak berbasis jaringan yang memerlukan komunikasi client-server stateless, dapat di-cache melalui antarmuka yang seragam antar komponen.

Fokus utama kita adalah mengenalkan REST bersama dengan terminologi REST, konsep REST, dan beberapa contoh sederhana yang menggambarkan seperti apa REST dalam praktiknya.

Prinsip Dasar

Komunikasi Client Server
Arsitektur client-server memiliki pemisahan keprihatinan yang sangat berbeda. Semua aplikasi yang dibangun dengan gaya RESTful juga harus menjadi client-server pada prnsipnya.

Stateless
Setiap permintaan dari setiap klien ke server mengharuskan state sepenuhnya terwakili. Server harus dapat sepenuhnya memahami permintaan klien tanpa menggunakan konteks server atau status sesi server. Ini berarti bahwa semua state harus disimpan pada klien.

Cacheable
Kendala cache dapat digunakan, sehingga memungkinkan data respons ditandai sebagai cacheable atau tidak-cachable. Setiap data yang ditandai sebagai cacheable dapat digunakan kembali sebagai respons terhadap permintaan berikutnya yang sama.

Uniform Interface
Semua komponen harus berinteraksi melalui satu antarmuka seragam. Karena semua komponen interaksi terjadi melalui interface ini, interaksi dengan berbagai layanan sangat sederhana. Antarmuka itu sama! Ini juga berarti bahwa perubahan implementasi dapat dilakukan secara terpisah. Perubahan seperti itu, tidak akan mempengaruhi interaksi komponen mendasar karena antarmuka seragam selalu tidak berubah. Salah satu kelemahannya adalah Anda terjebak dengan antarmuka. Jika pengoptimalan dapat diberikan ke layanan tertentu dengan mengubah antarmuka, Anda kurang beruntung karena REST melarang hal ini. Sisi baiknya, bagaimanapun, REST dioptimalkan untuk web, maka popularitas REST yang luar biasa melalui HTTP!
 
Konsep di atas mewakili karakteristik pendefinisian REST dan membedakan arsitektur REST dari arsitektur lain seperti layanan web. Hal ini berguna untuk dicatat bahwa layanan REST adalah layanan web, namun layanan web belum tentu layanan REST.

Mari selami sedikit detail dan diskusikan berbagai elemen yang digunakan untuk menyusun sistem RESTful.

Sumber Daya dan Sumber Daya Identifier:
Abstraksi kunci REST adalah sumbernya. Sumber daya bisa berupa apa saja. Ini bisa berupa dokumen atau gambar, objek, koleksi sumber daya lainnya, dan lainnya. Sumber daya diidentifikasi oleh pengenal sumber dayanya. Pengenal sumber daya sering digunakan saat banyak komponen berkomunikasi satu sama lain. Mereka dapat referensi sumber daya spesifik menggunakan sumber daya identifier.

Dalam prakteknya, sumber daya adalah kata benda. Sumber daya dan diidentifikasi oleh URI,
misalnya Sumber daya Mobil ini diidentifikasi oleh pengenal sumber daya, http://www.automart.com/cars/12345

Representation:
Komponen melakukan tindakan sumber daya dengan menerapkan operasi yang disediakan oleh komponen uniform interface. Sumber daya diwakili oleh keadaan saat ini atau keadaan yang dimaksudkannya (dengan asumsi tindakan akan mengubah sumber daya dengan cara tertentu). Representasi ini mencakup urutan byte dan beberapa deskripsi byte tersebut. Format representasi didefinisikan sebagai jenis media.

Dalam prakteknya, sumber daya sering digambarkan sebagai XML, JSON, RDF, dan banyak lagi

Prinsip Dasar dalam Praktek
Mari kembali ke bagian Prinsip Dasar dan jelaskan bagaimana prinsip-prinsip tersebut dapat diterapkan dalam praktik.

Client-Server
HTTP adalah protokol client-server. Mengapa tidak menggunakannya dengan REST.

Uniform Interface
REST dioptimalkan untuk web, sehingga HTTP biasanya digunakan. HTTP mendefinisikan GET, POST, PUT, DELETE. Itu memenuhi persyaratan REST untuk menyediakan antarmuka seragam untuk komponen.

Cacheable
HTTP menyediakan mekanisme kontrol cache. Lihat disini. HTTP hanya mengisi persyaratan REST yang lain.

Stateless
Tidak begitu mudah. Mari menerapkan beberapa aturan ke antarmuka seragam yang disediakan oleh HTTP
GET - Aman, Cacheable, Idempotent
PUT - Idempotent
DELETE - Idempotent
HEAD - Aman, Idempotent
POST - n / a

Apa artinya?
- Aman - operasi tidak boleh memiliki efek samping
- Cacheable - hasilnya mungkin di-cache misalnya oleh server proxy
- Idempotent - Operasi harus selalu mengembalikan hasil yang sama

REST Penggunaan Praktis

Mari sekarang berikan beberapa contoh penggunaan dalam praktik:

Resource and Resource Identifier
Contoh sumber daya adalah Mobil, Mesin, Bagian. Setiap sumber daya diidentifikasi oleh pengenal sumber dayanya. Sebagai contoh:
Mobil: http://www.automart.com/cars/12345
Bagian: http://www.automart.com/part/12345
Mesin: http://www.automart.com/engine/12345

Representation
Mobil kami dengan pengenal sumber daya, http://www.automart.com/cars/12343 dapat dimanipulasi oleh komponen melalui antarmuka seragam GET, POST, PUT, DELETE. Berikut adalah beberapa contohnya:
 
GET mengembalikan representasi negara sumber daya, Misalnya, http://www.automart.com/cars/12343.
 
Representasi XML tentang keadaan itu mungkin:
  <Mobil>
  <Make> Audi </ Make>
  <Model> A5 </ Model>
  <Tahun> 2013 </ Tahun>
  </Mobil>
atau di JSON
{
"Membuat": "Audi",
"Model": "A5",
"Tahun 2013
}

Representasi dengan Linked Resources
Representasi sumber daya mungkin berisi tautan ke sumber lain
misalnya
<Mobil>
  ...
  <Engine uri = "http://www.automart.com/engine/1242" />
  ...
</ Mobil>
atau di JSON
{
...
"mesin": "http://www.automart.com/engine/1242"
...
}