Yohanes Santoso <[EMAIL PROTECTED]> writes: > "Lukman Salim" <[EMAIL PROTECTED]> writes: > >> Sepengertian saya, REST itu untuk webservice, kalau tidak niat diekspos >> sebagai webservice tidak perlu menggunakan REST? > > Bisa tolong saya mengerti apa yang anda maksud? Saya tidak mengerti > apa yang anda maksud dengan 'webservice'. Apakah the term 'Web > Service' yang di push oleh IBM dan entities lainnya (W3C juga kah?) > yang artinya anything yang memakai SOAP dan XML? > > Lalu apa bedanya webservice yang diexpose (diexpose ke siapa?) dan > yang tidak diekspose? > > > > > > > Sementara menunggu penjelasan, saya pre-empt dulu sedikit untuk > memperpendek message exchanges. > > Sebelumnya saya bilang: > >>> [...] dan juga tidak semua applikasi RESTful memakai HTTP. Memang >>> kadang2x susah membedakan antara HTTP dan REST, tapi mereka tetap >>> dua hal yang berbeda. > > Mengingat bahwa REST itu bukan product, bukan protocol, tapi adalah > architectural style, kenapa tidak bisa di-apply ke architeture system > anda juga, baik system yang di-'expose' atau tidak di-'expose'. Saya > memakai tanda kutip karena saya masih belum tahu benar apa pengertian > 'expose' di pertanyaan anda. > > Architectural style itu artinya mendesign architecture system anda > dengan mengikuti beberapa constraints (apakah translasinya > 'panduan'?). Ini berarti bahwa anda harus menaruh restrictions di > design anda sedemikian rupa sehingga memenuhi constraintsnya. > > Menerapkan REST architectural style artinya 6 constrainst berikut ini > terpenuhi. Setiap constraints yang terpenuhi otomatis memberi beberapa > sifat2x atau characteristics. Saya copy-paste sifat2xnya dari [1]. > > + untuk advantage > - untuk disadvantage > > > 1. client-server > > + improve the portability of the user interface > + improve scalability by simplifying the server components > > > 2. stateless > > + Visibility is improved because a monitoring system does not have to > look beyond a single request datum in order to determine the full > nature of the request. > + Reliability is improved because it eases the task of recovering from > partial failures [133]. > + Scalability is improved because not having to store state between > requests allows the server component to quickly free resources, and > further simplifies implementation because the server doesn't have to > manage resource usage across requests. > - may decrease network performance by increasing the repetitive data > > > 3. cache > > + potential to partially or completely eliminate some interactions, > + improving efficiency, > + [improving] scalability, and > + [improving] user-perceived performance by reducing the average > latency of a series of interactions. > - [possible] stale data > > > 4. uniform-interface > > + overall system architecture is simplified > + the visibility of interactions is improved. > + encourages independent evolvability. > - degrades efficiency > > Untuk memenuhi constraint yang ini, aplikasi atau apapun yang bisa > diakses/mengaccess harus memenuhi 4 constraints tambahan: > > 4.1 identification of resources; > 4.2 manipulation of resources through representations; > 4.3 self-descriptive messages; > 4.4 and, hypermedia as the engine of application state. > > Untuk penjelasan lebih lanjut 4 constraints itu, silakan google karena > sudah banyak orang berkemampuan yang menulis tentang itu. Ini bukannya > suruhan RTFM (well, sedikit sih), tapi pernyataan bahwa saya bukan > sumber penjelasan terbagus dan ada penjelasan yang lebih baik dari > yang saya bisa buat. > > > 5. Layered System (each component cannot "see" beyond the immediate > layer with which they are interacting) > > + [restrict] the overall system complexity and promote substrate > independence. > + encapsulate legacy services > + protect new services from legacy clients, > + simplifying components > + improve system scalability by enabling load balancing > - add overhead > - [add] latency
Waduh, maaf, lupa constraint nomer 6. Untungnya ini optional constraints, jadinya tulisan saya yang lainnya tidak perlu diganti (contohnya "Jika architecture anda memenuhi 5 constraints itu"). 6. Code-On-Demand (contohnya mengirim JS code ke web browser) + reducing the number of features required to be pre-implemented. - reduces visibility > > Jika architecture anda memenuhi 5 constraints itu, maka dia akan > otomatis disebut RESTful architecture. Jika anda membuat sebuah > webapp untuk di Internet, maka 4 dari 5 constraints itu sudah otomatis > terpenuhi dan yang anda hanya perlu pastikan adalah 4 constraintsnya > uniform interface (4.1 -- 4.4 di atas).[2] > > Jika suatu hari anda, tanpa sengaja, mendesign sebuah architecture > yang memenuhi 5 constraints itu, tanpa peduli itu architecture untuk > apa, architecture anda disebut mengikuti REST style, aka. RESTful. > > Berhubung subject email ini adalah "RESTful rails", Roy Fielding ada > material[3] baru yang di-present di RailsConf Europe minggu lalu. Yang > menyinggung RoR hanya 1 dari 32 slides. Untuk saya yang sudah sering > baca tulisan2x dia sebelumnya, material yang paling saya sukai adalah > halaman 28: "and REST(ful) became the next industry buzzword. Yikes!" > dan 32: "always keep in mind that change is inevitable", "use > principled design". > > > YS. > > > > > > > Footnotes: > [1] http://www.ics.uci.edu/%7efielding/pubs/dissertation/rest_arch_style.htm` > > [2] Ini juga sebabnya kenapa orang2x (termasuk saya) biasa bilang > bahwa hanya perlu memenuhi constraints 4.1--4.4 untuk bisa dibilang > RESTful. Karena ada assumsi bahwa systemnya akan ditaruh di WWW, > menjadi salah satu bagian dari WWW, sehingga constraints 1-3,5 sudah > otomatis dipenuhi. Pengucapan selebor dan tidak precise, saya akui. > > [3] http://roy.gbiv.com/talks/200709_fielding_rest.pdf
