"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 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
