Lukman Salim wrote: > YS, thanks untuk penjelasan anda. Maksud saya web service adalah seperti > yang anda maksud, hanya tambahannya tidak hanya dengan SOAP karena sekarang > juga banyak menggunakan RESTful interface. > > Nah kalau aplikasinya tidak mengekspos web service ke luar, tentunya bahaya > seperti GET untuk delete bisa diminimalkan karena seluruh HTTP request ada > dalam kontrol developer sendiri, kecuali bila ada non user (seperti robot) > yang juga ikut2an menelusuri URL link di halaman web kita. Inipun sebenarnya > harusnya dilapisi dengan dialog konfirmasi sehingga tidak benar2 terjadi > perubahan dalam sistem (yang seharusnya tidak terjadi pada GET request). > Tapi memang kalau kita bisa disiplin dengan prinsip REST untuk setiap > aplikasi tentunya ini yang terbaik ya. > > Lukman > > Prinsip tersebut bukan hanya berlaku untuk REST cuma demi mengamankan "robot".
Ada banyak sekali orang yang menggunakan proxy server. Dan proxy server ini bekerja juga dengan asumsi yang sama seperti HTTP. Apabila Anda melakukan "GET" dengan proxy server, maka ada kemungkinan response tersebut akan di-cache. Pada saat orang lain melakukan GET dengan URL yang sama, proxy tidak akan mengontak server aslinya tapi langsung mengembalikan response yang sudah di-cache. Hal ini berhubungan dengan header-header yang ada dalam HTTP, terutama expiration, security, dan juga ada header2 yang mengatur cache. Cache ini juga ada di dalam browser kita. Jadi tidak harus ada proxy server. Kalau kita bisa mengoptimasi penggunaan HTTP, maka cache akan sangat membantu. Karena tidak harus ada transfer data yang tidak penting. Konfigurasi yang salah bisa mengakibatkan user experience menjadi buruk, apabila browser harus terus menerus mendownload data yang seharusnya dia sudah punya, jadinya kesannya situs lambat. Oya, konfirmasi (JavaScript) untuk mencegah penggunaan yang salah (konfirmasi delete, misalnya) tidak berlaku apabila JavaScript dimatikan dan juga apabila robot yang melakukan request (karena robot tidak akan menjalankan JavaScript tersebut). Lama2 it's not about REST vs non-REST..... mungkin lebih ke "bad design practices" vs "good design practices" (design = design cara kerja situs, bukan tampilan) > On 9/29/07, Yohanes Santoso <[EMAIL PROTECTED]> wrote: > >> Yohanes Santoso <[EMAIL PROTECTED]<yahoo-id-ruby%40microjet.ath.cx>> >> writes: >> >> >>> "Lukman Salim" <[EMAIL PROTECTED] <lukman.salim%40gmail.com>> >>> >> 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`<http://www.ics.uci.edu/%7efielding/pubs/dissertation/rest_arch_style.htm%60> >> >>> [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 >>> >> >> >> > > > [Non-text portions of this message have been removed] > > > > -- Hendy Irawan www.hendyirawan.com
