546
R. ATAM (Architecture Tradeoff Analysis Method, hlm 178)
Keputusan arsitektur menentukan kemampuan sistem yg diterapkan
utk memenuhi persyaratan atribut fungsional & berkualitas. Gaya arsitektur
Representational State Transfer (REST) telah banyak digunakan baru-baru
ini utk mengintegrasikan layanan & aplikasi. Adopsinya utk membangun
sistem terdistribusi berbasis SOA membawa bbrp manfaat, tetapi juga
menimbulkan tantangan & risiko baru. Yg sangat penting di antara risiko
tersebut adalah kegagalan untuk secara efektif memenuhi persyaratan
atribut berkualitas spt keamanan, keandalan, & kinerja. Teknik yg terbukti
efisien utk mengidentifikasi & membantu mengurangi risiko tersebut adalah
evaluasi arsitektur. Dlm tulisan ini diusulkan pendekatan, perkakas, &
pedoman utk membantu kegiatan evaluasi arsitektur dlm sistem berbasis
REST. Pedoman ini dpt digunakan secara sistematis bersama dgn metode
evaluasi utk alasan tentang pertimbangan desain & tradeoff. Utk
menunjukkan bgmn pedoman dpt membantu evaluator arsitektur, disajikan
bukti konsep yg menjelaskan cara menggunakan pedoman dlm evaluasi
ATAM (Architecture Tradeoff Analysis Method). Dipresentasikan hasil survei
yg dilakukan dgn spesialis industri yg telah melakukan evaluasi arsitektur dlm
sistem berbasis REST dunia nyata utk mengukur kesesuaian & utilitas
pedoman yg diusulkan. Akhirnya, dijelaskan alat Web yang dikembangkan
utk memfasilitasi penggunaan pedoman evaluasi. (Bruno Costa et al. 2015)
547
Metode Analisis Tradeoff Arsitektur (ATAM) adalah metode untuk
mengevaluasi arsitektur perangkat lunak relatif terhadap tujuan atribut
kualitas. Evaluasi metode memaparkan risiko arsitektur yang berpotensi
menghambat pencapaian tujuan bisnis organisasi. (Daniel Marczydło 2017)
Why Architectural Analysis? Semakin awal Anda menemukan masalah
dalam proyek perangkat lunak, semakin baik Anda. Arsitektur yang tidak
cocok akan membawa bencana pada sebuah proyek. Evaluasi arsitektur
adalah cara murah untuk menghindari bencana.
Participants in ATAM:
The evaluation team:o team leader,o evolution leader,o scenario and processing scribe,o timekeeper,o process observer.
Project decision makers. Architecture stakeholders:
o developers,o testers,o users,o builders of systems.
Kelak diusahakan semua partisipan ATAM bisa diakses oleh peneliti.
Team evaluasi bisa dianalogikan adalah: 1) Team leader – Promotor; 2)
Scenario and processing scribe – Copromotor1; 3) Evolution leader –
Copromotor2; 4) Timekeeper – S3 Admin; 5) Process observer – Peneliti S3.
548
Project decision makers bisa dianalogikan pemilik website system,
berkedudukan di Universitas Hasanuddin. Architecture stake holders adalah
developers, testers, users, dan builders of systems, terkait tiap website yang
diteliti.
The method consists of nine steps:
1. Present the ATAM.2. Present business drivers.3. Present architecture.4. Identify architectural approaches.5. Generate quality attribute utility tree.6. Analyze architectural approaches.7. Brainstorm and prioritize scenarios.8. Analyze architectural approaches.9. Present results.
Bisa dianalogikan di sini, step1, menyajikan ATAM di Bab3 disertasi.
Step2, menyajikan business drivers di Bab4. Step3, menyajikan architecture,
diketahui ada dua yaitu REST dan WS-*, di Bab3. Step4, mengidentifikasi
pendekatan arsitektural, di Bab2. Step5, membangkitkan quality attribute
utility tree, di Bab4. Step6, menganalisis architectural approaches, di Bab3.
Step7, brainstorm and prioritize scenarios, di masa pembimbingan. Step8,
menganalisis architectural approaches di Bab4. Step9, menyajikan hasil-
hasil, di Seminar Hasil.
Aliran konseptual ATAM:
549
Gambar 3.14. Aliran konseptual ATAM.
Phases of the ATAM (dilakukan penyesuaian dengan siklus disertasi):
Phase 0 activity: preparation participants: evaluation team leadership and key project decision
makers typical duration: proceeds informally as required, perhaps over a few
weeksPhase 1
activity: evaluation (steps 1-6) participants: evaluation team and project decision makers typical duration: 1 day followed by a hiatus of 2 to 3 weeks
Phase 2 activity: evaluation (steps 7-9) participants: evaluation team, project decision makers and
stakeholders typical duration: 2 days
Phase 3 activity: follow-up participants: evaluation team and evaluation client typical duration: 1 week
550
Outputs of ATAM:
A concise presentation of the architecture. Hal ini terkait dengan arsitektur RESTful dan WS-*
Articulation of business goals. Tujuan bisnis ditetapkan oleh pemilik website system. Biasanya terangkum dalam paparan visi, misi, taktik, dan strategi.
The quality requirement in terms of a collection of scenarios. Ketentuan kualitas koleksi scenario terkait norma standar REST dan WS-*
Mapping of architectural decisions to quality requirements. Pemetaan ini menjadi salah satu hasil disertasi di Bab4.
A set of identified sensitivity and tradeoff points.
A set of risks and non-risks. A set of risk themes.
Menjadi beberapa hasil disertasi yang dipaparkan dalam Bab4.
ConclusionsJika arsitektur perangkat lunak adalah aset bisnis utama untuk
organisasi, analisis arsitektur juga harus menjadi praktik utama bagi
organisasi tersebut. Mengapa? Karena arsitekturnya kompleks dan
melibatkan banyak trade off desain. Tanpa melakukan proses analisis formal,
organisasi tidak dapat memastikan bahwa keputusan arsitektur yang dibuat
— terutama yang mempengaruhi pencapaian atribut kualitas seperti kinerja,
ketersediaan, keamanan, dan modifiabilitas — disarankan yang secara tepat
mengurangi risiko.
551
S. Review
Sudah dijabarkan micro service taxonomy dari desain hingga
implementation di mana urusan REST & HTTP tercakup dalam technology
stack, bagian data exchange. Masih belum diuraikan pembahasan tentang
deployment hingga organizational aspects. Dilakukan pemeriksaan Web
Service yang tercantum dalam repositori berikut:
xmethods.net • webservicex.net • webservicelist.com • programmableweb.com
Hasil pertama:
Gambar 3.15. xmethods.net sudah tidak bisa diakses, walau pun masih banyak situs lain yang membahasnya.
Hasil kedua:
552
Gambar 3.16. webservicex.net sudah tidak bisa diakses, walau pun masih banyak situs lain yang membahasnya.
Hasil ketiga:
Gambar 3.17. Domain name webservicelist.com sudah dijual, walau pun masih banyak situs lain yang membahasnya.
Hasil keempat:
553
Gambar 3.18. programmableweb.com masih bisa diakses.
Pembahasan sebab-sebab kekurangsuksesan ketiga website
terdahulu dan keberhasilan website terakhir bisa menjadi entry point untuk
mengarahkan penelitian disertasi, didahului review tiga paper dari Unhas
terkait RESTful (plus WS-*) dan tiga paper (dari Andi Neuman dkk, Ralph
Johnson dkk dan Markos Viggiato dkk), simak uraian lengkap di Bab 2.
Disertasi ini berusaha menjawab challenges seperti permasalahan
optimalisasi komunikasi antar-services (expensive remote calls, testing the
whole system) dan eksekusi transaksi-transaksi (complex distributed
transactions, service faults) melalui pembahasan tentang RESTful dan WS-*
diawali dengan Architecture Tradeoff Analysis Method.
554
Sudah dikonfirmasi manfaat yang diberikan oleh layanan mikro, seperti
penyebaran independen, kemudahan untuk menskalakan aplikasi,
mempertahankan, dan tidak ada komitmen untuk satu tumpukan teknologi.
Juga ditegaskan tantangan yang mungkin dihadapi pengembang, seperti
transaksi terdistribusi yang kompleks, pengujian seluruh sistem, dan
kesalahan layanan.
Dua gaya web services digunakan side by side, diharapkan bahwa
mereka akan mulai memiliki efek positif satu sama lain. Dari paper yang
sempat diakses terkait Unhas: 1) ada satu desain dan implementasi REST
API untuk Academic Information; 2) Ada INTEGRASI SISTEM INFORMASI
PERPUSTAKAAN MENGGUNAKAN REPLIKASI DATA, untuk
menyelaraskan beberapa database-nya menggunakan metode RESTFul; 3)
Ada analisis kinerja GraphQL dan RESTful dalam SIM LP2M.
Gambar 3.19. Diketahui ada 59.500 hasil pencarian “universitas hasanuddin” dengan MS Bing, 24-02-2021.
555
Gambar 3.20. Mobile apps yang terkait unhas.ac.id
Selanjutnya diperiksa keterkaitan system “universitas hasanuddin”
dengan material yang dikandung website yang dibahas Gambar 3.15 hingga
3.18, plus untuk tiap system, mana saja web service style yang digunakan
(RESTful, WS-*, XML-RPC, JavaScript /AJAX, atau Others).
Selanjutnya diperiksa: 1) REST Concepts dalam Praktek, 2)
Identification of Resources, 3) Representations, 4) Self-descriptive
Messages, 5) HATEOAS, 6) Other important concepts.
556
REST Concepts dalam Praktek
Diprioritaskan web service di Universitas Hasanuddin yang dianalisis,
baik yang RESTful mau pun yang WS-* (misalnya prinsip SOAP dikodekan
dalam standar berbasis XML).
Dari jurnal pertama diketahui bahwa di Unhas ada Sistem Informasi
Perpustakaan menggunakan replikasi data. Integrasi system informasi
perpustakaan (Universitas & Fakultas) menggunakan web service
technology. Yang perlu digunakan dalam mengintegrasikan beberapa basis
data adalah bahasa pemrograman PHP. Diperlukan teknik yang dapat
menyamakan struktur table pada suatu database. Metode yang digunakan
untuk menyelaraskan beberapa database adalah RESTful. Metode ini bisa
diterapkan dalam proses pengiriman data antara client dan server.
Dari jurnal kedua diketahui bahwa di Unhas ada desain dan
implementasi REST API untuk Academic Information System. Penelitian ini
berkaitan dengan pengembangan prototipe dan analisis kinerja REST API
untuk sistem informasi akademik. Rest API dikembangkan menggunakan dua
teknologi server yang berbeda, NodeJS dan PHP. Prototipe dikembangkan di
atas server database menggunakan satu tabel sampel yang mewakili
pegawai di institusi pendidikan tinggi. Untuk setiap REST API yang
dikembangkan, terdapat 2 tipe titik akhir yang dibuat.
557
Eksperimen diatur dengan satu database yang berisi satu tabel dan
memanfaatkan Apache Jmeter untuk mensimulasikan hingga 1000
permintaan bersamaan. Hasil eksperimen menunjukkan implementasi
NodeJS dari REST API secara konsisten memiliki kinerja yang lebih baik
dibandingkan dengan Implementasi REST API berbasis PHP. Implementasi
NodeJS mencapai 100% throughput untuk hingga 1000 permintaan
bersamaan, sedangkan PHP mencapai 48,70% throughput saat melayani
jumlah permintaan bersamaan.
Dari jurnal ketiga diketahui di Unhas ada analisis kinerja GraphQL &
RESTful di SIM LP2M. GraphQL adalah konsep baru dlm membangun API.
GraphQL adalah Bahasa Kueri yg dikembangkan oleh Facebook dan
diimplementasikan di sisi server. Meskipun ini bahasa kueri, GraphQL tdk
terhubung langsung dgn database. GraphQL tidak terbatas pd database SQL
& NOSQL. GraphQL yg menggunakan titik akhir tunggal lebih efisien dr pd
RESTful yg menggunakan banyak titik akhir ttp GraphQL juga akan sedikit
lebih lambat dlm meng-kueri database yg kompleks dan memiliki banyak
hubungan, di samping itu REST dibangun di bbrp titik akhir utk menentukan
data pengembalian, sering kali bbrp titik akhir diperlukan utk dipanggil ketika
diperlukan. Ini akan meningkatkan jml panggilan klien-server utk
menampilkan data kepada pengguna dan ini mungkin dpt mengakibatkan
kinerja layanan yg lebih buruk dlm kebutuhan Aplikasi Web.
558
Makalah ini menganalisis perhitungan kinerja teknologi GraphQL dan
RESTful dalam sistem layanan informasi web Lembaga Penelitian dan
Pengabdian kepada Masyarakat (LP2M) Universitas Hasanuddin. Parameter
kinerja yang digunakan adalah Waktu Respons dan Throughput. Hasil kami
menunjukkan bahwa dalam hal kecepatan RESTful masih lebih unggul
daripada GraphQL karena kecepatan RESTful secara konsisten stabil dalam
hal waktu akses dan ukuran data. Sedangkan GraphQL dinamis karena
dapat berubah tergantung pada fluktuasi permintaan.
Sesuai dengan prinsip-prinsip REST, setiap sumber daya diidentifikasi
dengan URI. Menanggapi pesan HTTP, sumber daya kembali representasi
mereka kepada klien, atau klien memodifikasi sumber daya. Pendukung
Layanan Web RESTful biasanya mengatakan bahwa setiap layanan perlu
mengikuti CRUD model, yang mendefinisikan satu metode untuk membuat,
membaca, memperbarui, dan menghapus sumber daya di server (sesuai
dengan metode PUT, GET, POST, dan DELETE).
Salah satu contoh yang baik dari web services yang memiliki desain
RESTful yang tepat, yaitu: Amazon S3 (Simple Storage Service) [3]. S3
mendefinisikan sumber daya sejati dan menggunakan HTTP metode (GET,
PUT, POST, DELETE, bahkan HEAD) untuk memanipulasinya. Ini
menggunakan kode kesalahan HTTP dengan benar dan menunjukkan cara
memetakan berbagai kesalahan ke kode HTTP (API mereferensikan 13 kode
559
status HTTP unik dalam rentang 300-500). S3 juga mendukung caching
dengan menyertakan header ETag yang dapat digunakan klien dalam GET
bersyarat. Upaya ini bahkan lebih terpuji, karena layanan ini juga
mendefinisikan versi WS-*, sehingga akan menggoda untuk membuat versi
RESTful dengan langsung menerjemahkan WSDL ke sumber daya semu.
Identification of Resources
Mslh mengidentifikasi sumber daya mirip dgn mengajarkan desain
berorientasi objek kpd programmer, yg pertama kali diajarkan bahasa
prosedural - itu mem-bth-kan pola pikir yg berubah. Dlm desain berorientasi
objek, langkah ke-1 adalah mendefinisikan "hal-hal" atau "kata benda" sbg
object /class. Pd langkah ke-2, the public methods of the object didefinisikan.
Dalam masalah yang tidak sepele, kedua langkah ini mengidentifikasi
banyak objek dan banyak metode. Aplikasi ini dibangun dengan
menghubungkan objek, yang memanggil metode satu sama lain. Pendekatan
serupa dapat diterapkan untuk mendefinisikan sumber daya, kecuali bahwa
hanya langkah pertama yang mengidentifikasi banyak objek (yaitu sumber
daya). Metode HTTP yang tersedia didefinisikan dalam standar dan tautan
antar sumber daya dilalui pada waktu proses. Dengan demikian langkah
kedua dan ketiga datang secara gratis di HTTP, tetapi hanya jika langkah
pertama dilakukan dengan baik.
560
Gambar 3.21. Dilakukan identification of resources untuk RESTful system di Universitas Hasanuddin, disusun dalam suatu daftar Resource as URIs.
Representations
If resources support multiple representations, they can produce responses in different data formats. In HTTP, clients specify their preferred formats in Accept-* headers for content negotiation. By confirming to HTTP, RESTful Web services can support multiple types of response (MIME) formats, just like the Web does, which makes it easy to comply with this principle.
Bagai mana kondisi resources di RESTful system di Universitas
Hasanuddin? Respons-nya? Bagai mana clients men-spesifikasi formats?
Many RESTful Web services support at least two response formats (typically XML and JSON). Library of Congress Subject Headings Web service is the only service listed at programmableweb.com that advertises the support of content negotiation. It serves content in four different types (XHTML with embedded RDFa, JSON, RDF/XML, and N3). Unfortunately, other services do not appear to support this important feature of HTTP, because we did not find it in their documentation. Bagai mana kondisi Unhas?
561
Gambar 3.22. Bagai mana kondisi REST representations pada system di Universitas Hasanuddin? Bagai mana penjelasan terhadap semua milestones di gambar ini?
Gambar 3.23. Misalnya representation suatu resource dalam bentuk json dengan alasan tertentu. Bisa juga dalam bentuk XML dengan alasan lain.
562
Self-descriptive Messages
REST membatasi pesan yang dipertukarkan oleh komponen agar
memiliki deskriptif sendiri (yaitu definisi standar) untuk mendukung
pemrosesan interaksi oleh perantara (proksi, gateway). Bagai mana
kejadiannya di system Universitas Hasanuddin?
Tabel 3.10. Pembahasan GET dan POST.
No Keterangan GET POST
1 Early Web services were having difficulties understanding the differences between even these two methods.
Some services defined GET for sending all requests to resources, even if the requests had side effects.
2 initially, Bloglines, Flickr, and Delicious Web services defined GET for making updates to these services.
3 Other services specified that clients can use GET and POST interchangeably, which is obviously wrong.
4 Consequently, these services were misusing Web proxies and caches polluting them with non-cacheable content, because these Web systems rely on standard meanings of HTTP methods.
KOMENTAR: Di system Universitas Hasanuddin, apakah terjadi salah guna web proxies dan caches polluting seperti itu?
5 Since then, the offending APIs were modified, but the underlying problem of understanding the semantics of HTTP methods still remains.
KOMENTAR: Bagai mana modifikasi API yang terjadi? Apakah problem seperti itu masih terjadi di Unhas?
Salah satu alasan untuk kesulitan ini adalah bahwa metode CRUD
tidak cukup untuk mengekspresikan semua operasi dengan bersih. CRUD
563
mencakup operasi dasar, yang perlu digabungkan menjadi urutan untuk
mengimplementasikan bahkan transaksi paling sederhana. Itu sebabnya
banyak layanan RESTful mencoba untuk menyandikan operasi mereka ke
dalam URI di RPC meskipun mereka tahu bahwa itu melanggar REST.
Gambar 3.24. Operasi CRUD, bagai mana implementasi dalam Unhas?
Tabel 3.11. Metafora CRUD, perbedaan POST dan PUT tidak jelas.
GET PUT PATCH POST
Membawa representasi diproduksi oleh klien, yang harus digunakan server untuk mengganti kontennya (sehingga berfungsi sebagai buat dan perbarui).
server memutuskan cara menggunakan representasi yang dikirimkan oleh klien untuk memperbarui sumber dayanya.
Dalam studi kepatuhan HTTP server Web, kami menemukan bahwa server web dan perantara memahami dengan benar hanya metode GET dan POST.
Metode HTTP baru, PATCH, ditambahkan pada Maret 2010 [10]. Ini dimaksudkan untuk mengganti POST dengan menyediakan semantik yang lebih tepat untuk membuat pembaruan di server.
Dengan POST, klien tidak dapat menentukan bagaimana sumber daya akan diperbarui. Sayangnya, definisi PATCH tidak mendefinisikan struktur untuk memasukkan instruksi untuk memperbarui (ei.e patch) sumber daya.
564
HATEOAS
Hypermedia as the engine of application state means that neither client nor server
needs to keep the state of the exchange in a session, because all the necessary information
is stored in the exchanged HTTP messages (in the URI and the accompanying HTTP headers).
Defining self-contained links is critical for RESTful Web services, because these links make it
possible to traverse, discover, and connect to other services and applications.
Gambar 3.25. Pemaknaan HATEOAS.
Karena cache HTTP tidak dapat digunakan dalam kasus ini, layanan
harus menangani lebih banyak permintaan, yang mengalahkan tujuan
pembatasan tarif. Selang yang tampaknya tidak berbahaya (tetapi sering
terjadi) ini melanggar dua prinsip - identifikasi sumber daya dan HATEOAS;
itu juga mempengaruhi cacheability. Bagai mana solusi-nya di Unhas?
565
Other important concepts
Standar HTTP mendefinisikan arti dari kondisi kesalahan yang
berbeda dan beberapa mekanisme untuk caching. RESTful Web Services
yang sesuai harus mengikuti mereka. Bagai mana kondisi hal itu di system
Unhas? Apakah system itu mempekerjakan user-IDs sehingga tidak bisa
mengambil manfaat dari caching? Perlu diperhatikan dokumentasi di
RESTwiki.
Frameworks for Building RESTful Web Services
Apakah frameworks untuk membangun RESTful Web Services sudah
tercipta dalam system Universitas Hasanuddin, mulai dari tiga system yang
sudah disebutkan di awal.
Ada 10 kerangka kerja populer yang menyediakan dukungan otomatis
untuk membangun perangkat lunak sesuai dengan prinsip-prinsip REST.
Beberapa kerangka kerja, seperti Ruby on Rails dan Spring adalah
kerangka kerja Web generic. Apakah system Unhas juga mulai
menggunakan frameworks itu diawali oleh web generic yang sama? Secara
keseluruhan, kerangka kerja RESTful perlu menyertakan lebih banyak
fungsionalitas agar sepenuhnya mematuhi REST.
566
Ready for the Enterprise?
Arsitek sistem perusahaan /institusi mengutip keamanan, pesan yang
dapat diandalkan, dan transaksi sebagai pembeda utama antara layanan
RESTful dan WS-*. Agar siap untuk perusahaan, kerangka kerja RESTful
perlu mendukung fitur-fitur ini. Richardson dan Ruby menunjukkan
bagaimana konsep-konsep ini dapat diimplementasikan menggunakan HTTP.
Dimulai dari keamanan tingkat pesan dasar, cukup menggunakan
HTTPS. Hal ini sudah diterapkan misalnya pada Portal Student di SSO
Universitas Hasanuddin (unhas.ac.id). Bagai mana kemampuan yang lebih
kompleks seperti tanda tangan, enkripsi, atau federasi (memungkinkan pihak
ketiga untuk broker kepercayaan identitas) yang tidak dapat disediakan oleh
HTTP saja, apakah Unhas sudah mengatur?
Gambar 3.26. Ketika kita klik “Library” muncul pesan “Privacy error”.
567
Gambar 3.27. TLS adalah Transport Layer Security yang mengamankan privasi data, sedangkan SSL merupakan singkatan dari Secure Sockets Layer yang merujuk pada jenis keamanan digital yang memperbolehkan komunikasi dienkripsi di antara website dan web browser. SSL sudah tidak lagi digunakan dan digantikan sepenuhnya oleh TLS.
Pengertian HTTPS merujuk pd ekstensi HTTP. Website yg menginstall
dan mengaktifkan sertifikat SSL/TLS dapat menggunakan protokol HTTPS
untuk membuat koneksi yang lebih aman dengan server (Apa Itu SSL/TLS? Cari
Tahu Juga Pengertian HTTPS dan Hubungan Keduanya – JUPRIYADI (wordpress.com)).
Jika keamanan, pesan yang dapat diandalkan, dan transaksi berhasil
diselesaikan, layanan RESTful juga harus memastikan skalabilitas. Terkait
hal itu, bagai mana penggunaan Amazon S3?
568
Open Research Problems of RESTful Services
Bagai mana pemeriksaan system Universitas Hasanuddin terkait: 1)
versi otoritatif standar HTTP dan URI yang menentukan karakteristik unik
Web [Fielding]; 2) Penautan HTTP, HTTP PATCH, Templat URI, dan OAuth?
Caching
Pada hari-hari awal sebagian besar konten statis, 24-45% lalu lintas
Web khas dapat di-cache. Saat itu, kisaran perkiraan adalah 20-30%, yang
sangat mengesankan mengingat seberapa dinamis konten Web. Sekarang
berapa prosentase untuk kasus system Universitas Hasanuddin?
Sebagian besar layanan RESTful tidak mendapat manfaat dari
caching: banyak kerangka kerja tidak mendukung caching, dan URI khas
tidak ramah cache, karena RESTful Web Services memerlukan info
pengguna dalam setiap permintaan.
Telah dibahas bagaimana user-ID digunakan untuk pembatasan tarif.
Tidak mungkin Web Services akan pernah mengubah kebijakan ini.
Sebaliknya, akan lebih baik untuk memindahkan informasi spesifik pengguna
keluar dari URI, sehingga respons masih dapat di-cache. Bagai mana
penanganan hal ini di system Universitas Hasanuddin?
569
Penambahan HTTP Linking yang akan datang (untuk meningkatkan
validasi cache) menunjukkan bahwa komunitas HTTP menghargai cache.
Namun, sangat sulit untuk mengikuti semua variasi: header caching, tag,
kedaluwarsa, dan metode bersyarat. Bagai mana kondisi system Unhas?
Caching sangat kompleks sehingga bahkan spesifikasi HTTPbis yang
akan datang dari IETF membagi topik ini menjadi dua dokumen (Caching
proper and Conditional Requests). Cache tidak unik untuk Web: caching
dalam arsitektur komputer dipahami dengan baik. Kami tidak memiliki model
caching tunggal yang konsisten di Web. Identifying 10 common web site caching
issues and their solutions | Off-Site Services New York WordPress, Drupal, Angular and
Node.js development and support (oss-usa.com).
Maintainability
Typical maintenance tasks of Web services (adding new features, fixing service APIs)
affect services themselves, their documentation, the client code, and even the development
tools. Since RESTful Web services are still prone to wholesale changes, each of these facets
offers ample opportunities for research. For example, it would be easier to develop
RESTful frameworks if they were more RESTful themselves. Alternatif yang
mungkin untuk menggunakan anotasi dalam kerangka kerja RESTful adalah
Atom Publishing Protocol (APP).
570
Atom adalah kosa kata XML untuk menggambarkan penerbitan
semantik; ini adalah format umpan sindikasi populer. APP mendefinisikan
representasi sumber daya dengan memperluas Atom. APP menentukan cara
mengakses resource melalui metode HTTP dan mendukung penambahan
ekstensi ke APP Spesifikasi.
Tidak seperti anotasi, APP dibangun menggunakan konsep REST. Ini
dapat digunakan dalam kerangka kerja RESTful untuk menentukan
hubungan antara kode klien dan konstruksi HTTP pada tingkat abstraksi yang
lebih tinggi. Bagai mana pengembangan APP di lingkungan system Unhas?
Security and Privacy
Dibandingkan dengan kerangka kerja WS-Security, layanan RESTful
mengandalkan berbagai add-on yang bekerja di atas HTTP. HTTPS banyak
digunakan untuk kerahasiaan, tetapi hanya menyediakan keamanan hop-by-
hop. Pengembang harus mengadopsi mekanisme keamanan tingkat pesan.
Tidak seperti WS-*, tidak ada standar yang harus diikuti, tetapi praktisi
REST mengikuti berbagai arsitektur referensi, misalnya layanan Amazon S3.
Dia juga menggabungkan stempel waktu untuk menjaga agar tidak meminta
pemutaran ulang. Various client-side and server-side filters should be
employed to validate the content. Hal ini bisa menjadi bahan riset disertasi.
571
Teknologi untuk mendukung autentikasi untuk layanan berbasis HTTP,
misalnya OpenID untuk identitas federasi, dan OAuth 1.0 untuk autentikasi
dan berbagi data. Protokol ini membuka jalan baru penelitian. Protokol lain
yang muncul adalah XAuth, platform terbuka untuk memperluas layanan
pengguna terautentikasi di seluruh web, yang memiliki banyak masalah
keamanan terbuka.
Menyimpan URI RESTful dalam log web dapat menyebabkan
masalah privasi jika log tidak dilindungi dan dianonimkan. Layanan WS-*
tidak menyimpan data sensitif di HTTP method signature and query strings.
URI RESTful menjadi jejak audit, dan mereka harus dianonimkan.
Researchers also need to figure out how the security measures fit the REST
model.
Gambar 3.28. Posisi URI RESTful.
572
QoS
When multiple providers offer the same service, a client has a choice and can select
the most suitable one. Often, this choice comes down to the Quality of Service (QoS)
parameters. RESTful Web services today ignore QoS requirements; their only concern is
providing functional interfaces. To add QoS parameters to RESTful services, a language for
describing the parameters and a mechanism to incorporate the description in the HTTP
payload is needed. Defining a standard QoS description language might benefit from the
work in Semantic Web. Semantic Web ontologies define standard ways of interpreting
information, such as QoS parameters, enabling all clients to interpret them the same way.
Ada UFM Enterprise REST API Guide v6.5.2 yang patut
disimak dan dipelajari di URL Enhanced QoS REST API - UFM Enterprise REST API
Guide v6.5.2 - Mellanox Docs. Dokumen tentang A Maturity Model for Semantic
RESTful Web APIs juga penting diperhatikan di URL (19) (PDF) A Maturity Model
for Semantic RESTful Web APIs (researchgate.net). Juga dokumen tentang RESTful
Grounding Web Ontology to enable RESTful Semantic Web Services di URL
RESTful Grounding by otaviofff.
Studies of Existing Systems
Urutan pertama adalah untuk mengidentifikasi prinsip-prinsip yang
baik untuk membuat perbandingan (REST dan WS-*). Zarras
mengidentifikasi prinsip-prinsip berikut untuk membandingkan infrastruktur
573
middleware: keterbukaan, skalabilitas, kinerja, transparansi distribusi. Properti
arsitektur perangkat lunak adalah sumber prinsip lain untuk dipertimbangkan.
Kemungkinan lain adalah menerapkan kembali pendekatan berprinsip, yang
digunakan oleh Fielding untuk mendapatkan REST, untuk menentukan gaya
arsitektur RESTful dan WS-*. Ini akan memerlukan penerapan batasan
tambahan, satu per-satu, untuk mendapatkan definisi lengkap dari gaya
arsitektur. Bagai mana penerapan ini untuk studi kasus system di Unhas?
Conclusion
Kedua gaya (RESTful dan WS-*) sedang digunakan di semua domain.
Tantangan baru adalah menggunakannya dengan benar, dan untuk dapat
menyelaraskannya untuk menyelesaikan masalah nyata perusahaan
/institusi. Dapatkah layanan RESTful meningkatkan skala hingga tantangan
ukuran perusahaan?
Bisnis semakin banyak menyebarkan layanan mereka di web, dalam
bentuk: 1) aplikasi web, 2) layanan SOAP, 3) layanan berbasis pesan, dan,
baru-baru ini, 4) layanan REST. Meskipun gerakan menuju REST diakui
secara luas, tidak ada banyak informasi konkret mengenai fitur teknis yang
digunakan di lapangan, seperti: a] format data biasa, b] bagaimana HTTP
kata kerja digunakan, atau c] struktur URI khas, hanya untuk beberapa nama.