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.