Fungsi PHP ( stristr dan substr )

FUNGSI PHP ( stristr dan substr )

            Pada pembahasan kali ini saya akan menjelaskan tentang dua  fungsi PHP string yaitu stristr dan substr. Pada dasarnya dua fungsi ini digunakan untuk memanipulasi suatu string untuk dapat digunakan sesuai keinginan.

I.                    STRISTR

Fungsi stristr digunakan untuk mencari dalam suatu kalimat sebuah kata atau lebih. Misalkan :

$kalimat =  “Saya tidak belajar programming”;

Dan kita ingin mencari kalimat dengan kata kunci “suka”. Maka cara mengambil atau memilih kalimat tersebut adalah sebagai berikut:

<?php

//mendefinisikan variabel $kalimat

$kalimat = "saya suka belajar Programing";

//fungsi like pada PHP

$kata = stristr($kalimat,'suka');

//tampilkan kata terpilih

echo "$kata";

?>

Output :

suka belajar Programming

        Jadi stristr akan mencari dalam kalimat tersebut yang mengandung kata suka, dan memotong kalimat dari kata suka sampai akhir kalimat. Sehingga keluar tampilan : suka belajar programming.

II.                 SUBSTR

     Fungsi PHP substr pada dasarnya digunakan untuk mencari kalimat berdasarkan urutan karakter tersebut. Misalkan jika kita memiliki kata ‘Hello world”, kata “Hello world” terdiri dari 11 karakter, dan kita ingin mengambil kata world saja maka dari kalimat “Hello world” kita tahu bahwa karakter “w” yang mengawali kata “world” berada pada urutan ke-7 setelah karakter spasi (spasi juga dihitung sebagai karakter) dalam kalimat “Hello world”, sedangkan kata “world” terdiri dari 5 karakter setelah urutan ke-7, untuk mengambil kata “world” kita mengetahui bahwa kata “world” berada di depan karakter spasi yang mempunyai urutan ke-6 ([spasi]world). Maka cara menggunakan fungsi substr adalah substr(“Hello world”,urutan karakter sebelum kata yang dicari(6), panjang karakter kata(5)) maka akan didapat kata “world”. Scriptnya sebagai berikut :

<?php

//mendefinisikan variabel $kalimat

$kalimat = "Hello world";

//fungsi substr akan digunakan untuk mengambil kata "world"

$kata = substr($kalimat,6,5);

//tampilkan kata terpilih

echo "$kata";

?>

Output :

world

Fungsi substr tidak terbatas untuk mengambil kata saja namun juga bisa digunakan untuk mengambil karakter yang kita inginkan berdasarkan urutan karakter tersebut. Tinggal kita kombinasikan urutan karakter dan panjanjang karakter. Sehingga didapatkan karakter yang diinginkan.

Pada kedua fungsi diatas dapat dikombinasikan untuk memanipulasi string yang ada. 

Terima kasih, silakan di-copy, silakan belajar programming jika berkenan silakan tambahkan pesan yang membangun, tetep semangat...tak ada kata gagal untuk orang yang selalu berusaha...

salam,Yogyakarta 7 Oktober 2013

Ikhwan Anshori

Pengertian RSS ( Learing About RSS )

[RSS]

Daftar headline sebuah situs disimpan dalam format XML, yang disebut dengan RSS yang sering juga dijuluki “RSS news Feed”. Karena formatnya XML dan standar maka dengan menggunakan regex maupun parser XML, RSS akan mudah di dapat.

 RSS

RSS digunakan untuk menggambarkan standar de facto untuk sindikasi konten Web. RSS adalah berbasis XML dan dapat digunakan dalam cara yang berbeda untuk distribusi konten, penggunaan yang paling luas adalah untuk mendistribusikan berita utama di Web.

Jadi, sebuah situs web mengizinkan situs lain untuk mempublikasikan beberapa isinya dengan sebuah dokumen RSS . Pengguna dapat membaca konten RSS yang terdistribusi dan dapat menggunakan konten pada situs yang berbeda. Konten tersebut dapat mencakup seperti feed berita, daftar acara, berita, headline, update proyek, kutipan dari forum diskusi atau bahkan informasi perusahaan.

Karena ada berbagai versi RSS, istilah yang paling sering digunakan sebagai nama untuk berarti sindikasi konten Web, situs web berita dan blog. Singkatan ini biasanya mengarah ke :

RDF Site Summary (RSS 0.9, RSS 1.0)

Rich Site Summary (RSS 0,91, RSS 1.0)

Really Simple Syndication (RSS 2.0)

Sejarah RSS

RSS dimulai dari 1995 oleh Ramanathan V. Guha, dikembangkan sebagai Meta Content Framework (MCF). MCF bertujuan mendeskripsikan obyek, atribut-atributnyadan hubungan antara mereka. Berikutnya Tim Bray, salah satu pionir XML, memindahkan MCF kedalam format berbasis XML, disebutnya Resouce Description Framework (RDF). RDF didefiniskan oleh World Wide Web Consortium (W3C) sebagai "a general-purpose language for representing information in the World Wide Web". RDF secara spesifik didesain untuk merepresentasikan metadata dan relasi antar hal, termasuk dasar dari konsep yang disebut Semantic Web. Sejarah perkembangan RSS tak bisa dilepaskan dari keterlibatan raksasa-raksasa software dan internet.

 Perang browser di era 90-an antara Microsoft dan Netscape, pada saat XML masih belum cukup matang diterima sebagai cara standar untuk memformat data, membuat Microsoft memunculkan konsep Channel Definiton Format (CDF). CDF sudah berbasis XML, dapat mendeskripsikan rating, jadwal, logo dan metadata situs. Diperkenalkan mulai Internet Explorer 4.0, yang kemudian bisa diimplementasikan ke Windows desktop dalam bentuk Active Desktop.

                Sementara MCF juga sudah lebih jauh lagi dengan XML, menjadi RDF sejak 1999. RSS pertama kali muncul pada Netscape Portal "My Netscape" sebagai RDF Site Summary, dimana user dapat mempersonalisasikan halaman mereka dengan apapun yang bisa didapat dari internet melalui itu, lalu mengaksesnya melalui sebuah file RSS.

 Draft pertama dari format RSS didesain oleh Dan Libby. Format ini ini menyederhanakan banyak hal dari RDF, bagi pengguna. Format ini kemudian dikenal sebagai RSS 0.91 yang menjadi jah lebih populer daripada RDF. Adalah Dave Winner dari Userland Software yang sangat vokal mengenai hal ini. Bagaimana menyederhanakan format XML yang digunakan. Pada akhirnya RSS 0.91 benar-benar berbeda dari RDF, tapi yang penting dapat divalidasi oleh XML parser manapun dan menjadi jauh lebih sederhana bagi

RSS Feed

Hampir setiap situs atau blog memiliki Feed (umpan) baik atom.xml, RSS, dan lainnya. Fungsi dari RSS Feed adalah mempermudah pembaca untuk selalu up to date dengan tulisan-tulisan yang disajikan oleh situs atau blog yang mereka sukai. Tentunya tanpa mereka berkunjung langsung ke situs/blog tersebut.

Manfaat RSS

• Menjalin hubungan lebih erat dengan pelanggan. Pelanggan yang mendaftar RSS anda akan terus mendapatkan informasi terkini mengenai bisnis anda.
• Hasilkan lebih banyak traffik. Memanfaatkan RSS akan menghasilkan lebih banyak traffik buat anda.
• Jaminan konten sampai. Beda dengan email marketing yang kadang tak sampai 100% berhasil masuk ke email pelanggan, menggunakan RSS pasti sampai ke alat RSS mereka.
• Pengunjung mudah mensubscribe. Mendaftar di RSS sangat mudah. Pengunjung tak repot untuk melakukannya.
• Menerbitkan konten sangat mudah. Update konten terbaru akan sampai di RSS reader pembaca.
• Mudah menyebar di internet. Melalui RSS, konten dan berita dari website anda mudah tersebar secara luas di internet.
• Membuat pengunjung datang lagi. Pengunjung yang baru pertama kali datang ke website atau blog anda, setelah mendaftar di RSS, besar kemungkinan akan datang kembali.
• Membentuk target kontak tertarget. Secara otomatis, mereka yang tak tertarik dengan konten anda tak akan mendaftar. Sebaliknya mereka yang tertarik akan mendaftar.
• Tempat iklan. Sekalipun perkembangan iklan di RSS tak sekencang di tempat lainnya, namun tak menutup kemungkinan nantinya akan menjadi salah satu alternatif utama beriklan.
• Melihat kebiasaan pengunjung. Melalui RSS  juga bisa dilacak bagaimana kebiasaan pelanggan RSS anda. seberapa sering membaca dan mengklik link konten anda melalui feed.

Demikian artikel yang bisa saya jelaskan tentang RSS, silakan di-copy, silakan belajar, jika sempat silakan tambahkan pesan yang membangun untuk memperbaiki artikel ini, terima kasih.

Perbedaan Web Service Soap Dengan Rest ( Soap Vs Rest Web Service)

  SOAP VS REST

Web Service

By Ikhwan Anshori

Yogyakarta 6/17/2013

 

PERBEDAAN WEB SERVICE SOAP DAN REST

Web service merupakan kunci integrasi untuk aplikasi-aplikasi yang berbeda platform, bahasa, dan sistem. Dengan kata lain kita dapat menyebut web service sebagai "titik temu bisnis".

REST masih cukup baru, sedangkan SOAP telah merevolusi RPC dan lebih terbuka dibanding batasan-batasan yang ada di versi sebelumnya.

Terminologi

·         SOAP adalah Simple Object Access Protocol

·         HTTP berbasis API berarti API yang diekspos sebagai salah satu atau lebih HTTP URI dan respon berupa XML/JSON. Skema respon dapat dikustomasi untuk setiap objek

·         REST pada sisi yang lain menambahkan sebuah elemen untuk menggunakan URI standar, dan juga memberikan kepentingan kepada penggunaan HTTP (seperti GET/POST/PUT, dsb.)

Meskipun beberapa tahun ini kita melihat perkembangan teknologi web service, tetapi popularitas SOAP tetap tidak berkurang. Arsitektur internet  datag dengan argumen yang bagus untuk  menekan soap di sisi yang lain: ada metode yang lebih baik untuk membangun web service dalam bentuk Representational State Transfer (REST).

REST lebih kepada filosofi lama, ketimbang sebuah teknologi yang baru. Tetapi dalam kenyataannya datang kemudian dalam teknologi. Sedangkan SOAP nampak seperti lompatan baru ke fase selanjutnya dalam pengembangan internet dengan sekumpulan spesifikasi baru, filosofi REST mendukung bahwa prinsip dan protokol yang sudah ada di Web cukup untuk membuat web servide yang kuat (robust). Hal ini berarti bahwa developer yang mengerti HTTP dan XML dapat mulai membangun web service tanpa membutuhkan toolkit di belakang apa yang biasanya digunakan dalam pengembangan aplikasi internet.

Dalam arsitektur REST, kunci resource diidentifikasi, dapat berupa entitas, koleksi, atau yang lain dimana nampak lebih bernilai ketika memiliki URI sendiri. Metode standar _ dalam kasus ini, cara kerja HTP, dipetakanke semantik-semantik resource-specific. Semua resource mengimplamentasikan interface yang seragam. Dimensi tipe konten, yang mengijinkan representasi berbeda dari resource-resource ( dalam XML, HTML, dan plain text), sebaik kemampuan links ke resource dalam representasi resource. Pikirkan, misal GET pda /customer/4711 akan mengembalikan dokumen yang mengandung link secara spesifik /order/xyz.

Saat ini dapat kita lihat sendiri bahwa banyak web service baru yang dkembangkan menggunakan arsitektur REST dibandingkan dengan SOAP. Mari kita lihat sekilas dan pahami poin-poin dasar apa itu REST.

REST web service

REST pada dasarnya setiap URL unik adalah representasi dari beberapa objek. Kita dapat memperoleh konten-konten objek tersebut menggunakan HTTP GET, untuk menghapusnya, kita dapat menggunakan POST, PUT, atau DELETE untuk memodifikasi objek (dalam praktiknya, kebanyakan service menggunakan POST untuk ini).

Contoh Aplikasi menggunakan REST web service

Semua web service utma di internet sekarang menggunakan REST: Twitter, Yahoo, termasuk Flickr, del.icio.us, pubsub, bloglines, technorati, dan beberapa yang lain. eBay dan Amazon menggunakan baik REST maupun SOAP.

Penggunaan SOAP web service

SOAP digunakan pada aplikasi-aplikasi Enterprise untuk mengintegrasikan penggunaan yang lebih luas dan banyak aplikasi dan tren yang lain adalah mengintegrasikan dengan legacy system (sistem lama yg sudah ada sebelumnya). Dalam internet, Google konsisten dalam mengimplementasikan web service mereka menggunakan SOAP, kecuali Blogger yang menggunakan XML-RPC.

 

Gambar Skema SOAP Web Service

REST vs SOAP

Perusahaan-perusahaan yang menggunakan REST API belum banyak, API yang mereka gunakan kebanyakan muncul baru-baru ini. Jadi REST sesungguhnya adalah aturan untuk membuat web service. Tetapi, mari perhatikan, gunakan konsep "SOAP to wash and your REST when you tired". Keuntungan utama web service REST yaitu:

·         lightweigt, tidak membutuhkan XML markup tambahan

·         hasilnya dapat dibaca dengan mudah oleh manusia (human readable result)

·         mudah untuk dikembangkan, tidak membutuhkan toolkit

SOAP juga mempunyai beberapa kelebihan:

·         mudah untuk dikonsumsi (kadang-kadang)

·         rigid (lebih kaku/ketat), dalam type-checking, harus mematuhi aturan penulisan

·         membutuhkan tools pengembangan

Apakah akses SOAP lebih mudah/sederhana? Sepertinya tidak! Mari kita lihat perbandingannya sebagai berikut:

API Flexibility & Simplicity

Kunci metodologi REST adalah untuk menulis web service menggunakan antarmuka yang sudah tersedia dan banyak digunakan: URI. Sebagai contoh, service/layanan untuk mengkonversi mata uang, yang mana seorang user memasukkan simbol mata uang untuk mengembalikan harga mata uang secara real-time, dapat dilakukan semudah membuat script yang dapat diakses melalui web server seperti URI:  http://www.ExampleCurrencyBrokerage.com/convert?=us-dollar&value=100&target=pound.

Aplikasi client atau server dengan dukungan HTTP dapat dengan mudah memanggil service tersebut dengan command HTTP GET. Berdasar pada bagaimana cara penyedia service menulis script, hasil respons HTTP kan menjadi lebih simpel seperti beberapa header standar dan string teks yang mengandung harga terkini untuk symbol yang diberikan. Atau, dapat berupa dokumen XML.

Metode antarmuka ini mempunyai keuntungan signifikan dibanding service berbasis SOAP. Developer dapat mengetahui bagaimana untuk membuat dan memodifikasi sebuah URI untuk mengakses resource yang berbeda. SOAP, pada sisi lain, membutuhkan pengetahuan khusus untuk spesifikasi XML, dan kebanyakan developer akan membutuhkan SOAP toolkit untuk membentuk request dan menguraikan (parsing) hasilnya.

Penggunaan Bandwidth - REST lebih ringan

Keuntungan lain dari antarmuka RESTful adalah request dan respon dapat dipendekkan. SOAP membutuhkan XML wrapper untuk setiap request dan response. Sekali saja namespace dan penulisan dideklaraskan, empat atau lima digit stock quote dalam respon SOAP bisa membutuhkan lebih dari sepuluh kali lipat sebanyak byte-byte respon yang sama ketika diimplementasikan menggunakan REST.

Para pendukung SOAP berpendapat bahwa penulisan kode yang rigid (kuat) merupakan fitur yang dibutuhkan dalam aplikasi terdistribusi. Dalam praktiknya, meskipun, keduanya (aplikasi request dan service) mengetahui tipe data dari waktu ke waktu, tetapi mengirimkan informasi tersebut dalam bentuk request dan respon hanyalah sebagai alasan.

Bagaimana seseorang tahu tipe data dan lokasinya dalam respon-dari waktu ke waktu? Seperti SOAP, REST masih membutuhkan dokumen yang saling berkaitan yang dapat menguraikan parameter input dan data output. Kabar baiknya adalah REST cukup fleksibel sehingga developer dapat menulis file WSDL untuk service-service tersebut jika dibutuhkan deklarasi secara formal. Jika tidak, deklarasi dapat sesederhana halaman web yang dapat terbaca manusia (human-readable Web) yang mengatakan "Berikan service ini sebuah input melali beberapa simbol harga saham, dalam format q=simbol dan itu akan menghasilkan kembalian harga saat inisebagai bagian saham sebagai string teks".

Security

Mungkin hal menarik dari perseteruan REST vs SOAP adalah sudut pandang security (keamanan). Meskipun SOAP menegaskan bahwa untuk mengirimkan remote procedure calls (RPC) melalui port standar HTTP adalah cara yang baik untuk memastikan dukungan web service melalui aturan-aturan yang ada. Namun, para pendukung REST berpendapat bahwa praktik tersebut adalah sebuah kekurangan utama yang membahayakan keamanan jaringan. Panggilan-panggilan REST juga dapat melalui HTTP atau HTTPS, tetapi dengan REST, administrator (firewall) dapat membedakan maksud dari setiap pesan dengan menganalisis perintah HTTP yang digunakan saat request. Sebagai contoh, request GET selalu dianggap aman karena ia tidak dapat, menurut definisi, memodifikasi data apapun. Dan itu hanya dapat meng-query kan data.

Request SOAP secara tipikal akan menggunakan POST untuk mengkomunikasi dengan service yang diberikan. Dan tanpa melihat envelope SOAP (tugas yang digunakan untuk mengkonsumsi keduanya dan tidak disertakan pada kebanyakan firewall) tidak ada cara untuk mengetahui apakah request tersebut hanya ingin meng-query data atau menghapus seluruh tabel dari database.

Adapun untuk otentikasi dan otorisasi, SOAP menempatkan beban pada pengembang aplikasi. Metodologi REST tidak memperhitungkan fakta bahwa web server sudah memiliki dukungan untuk tugas-tugas tersebut. Melalui penggunaan sertifikat standar industri dan sistem manajemen identitas umum, seperti server LDAP, developer-developer dapat membuat layer jaringan melakukan langkah berat.

Ini tidak hanya memudahkan para developer, tetapi juga memudahkan administrator, yang dapat menggunakan sesuatu semudah file ACL untuk mengontrol web service layaknya menggunakan URI yang lain.

REST tidak Sempurna

Sejujurnya, REST tidaklah sempurna. REST bukanlah solusi terbaik untuk setiap web service. Data yang butuh keamanan seharusnya tidak dikirimkan sebagai parameter dalam URI. Dan data dalam jumlah besar, seperti layanan pembelian, dapat menjadi rumit bahkan di luar batas URI.

Dan ketika metode web service diintegrasikan dengan attachment, SOAP adalah juaranya. SOAP dapat mengirimkan semua teks dan binary-binary tanpa  kesalahan. Dalam beberapa kasus, SOAP sesungguhnya adalah solusi yang tepat. Tetapi sangat penting untuk mencoba REST terlebih dahulu dan gunakan SOAP hanya bila diperlukan. Ini akan membantu menjaga pengembangan aplikasi secara sederhana dan mudah diakses.

Untungnya, filosofi REST dapat ditangkap para developer web service. Versi terbaru dari spesifikasi SOAP saat ini mengijinkan beberapa tipe service yang dapat dipaparkan melalui URI (meskipun respon masih berupa pesan SOAP). Demikian pula platform Microsoft .NET dapat mempublikasikan service-service sehingga dapat menggunakan request-request GET Semua ini menandakan pergeseran pemikiran tentang bagaimana membuat interface terbaik untuk web service.

Developer perlu memahami bahwa pengiriman dan penerimaan pesan SOAL tidak selalu cara terbaik bagi aplikasi untuk berkomunikasi. Kadang-kadang interface REST sederhana dan respon plain teks dapat menyelesaikannya dan juga  lebih banyak menghemat waktu dan resource dalam prosesnya.

Type Handling

SOAP menyediakan aturan penulisan yang ketat sejak mempunyai sekumpulan tipe-tipe data. Oleh karena itu menjamin bahwa return value (nilai kembalian) aka tersedia secara langsung dalam tipe native yang berkorespondensi pada platform tertentu. Pengetikan return value HTTP berbasis API harus diserialisasi dari XML, kemudian baru disesuaikan cara penulisannya. Ini tidak mewakili banyak usaha, musalnya untuk bahasa pemrograman dinamis. Faktanya, bahkan pengetikan objek-objek kompleks, traversing sebuah object sangat mirip dengan traversing XML tree, sehingga disini tidak ada manfaat yang jelas dalam kemudahan client-side coding.

Kompleksitas Cient-side

Membuat panggilan ke suatu HTTP API secara signifikan lebih mudah daripada membuat panggilan ke SOAP API. SOAPAPI membutuhkan library client, membutuhkan pengenalan, dan butuh kebiasaan. Sedangkan HTTP API adalah asli dari semua bahasa pemrograman dan hanya melibatkan request HTTP  dengan parameter sesuai yang ditambahkan. Bahkan secara psikologis, tipe yang pertama sedikit tidak memerlukan usaha.

Testing dan TroubleshootingBI

HTTP API juga mudah untuk di tes dan troubleshoot  karena dapat membangun pangglan dengan tidak lebih dari sekedar browser dan memeriksa respon dalam jendela browser itu sendiri. Tidak ada tool trubleshooting yang dibutuhkan untuk menghasilkan siklus request/response. Dalam hal ini tidak dapat dipungkiri bahwa HTTP berbasis API lebih unggul.

Kompleksitas Server-side

Kebanyakan bahasa pemrograman membuat kompleksitas server-side menjadi sangat mudah untuk menerangkan sebuah method melalui SOAP. Serialisasi dan deserialisasi ditangani oleh SOAP Server Library. Untuk menerangkan metode objek sebagai HTTP API dapat secara relatif lebih menantang karena memerlukan serialisasi output ke XML. Membuat API REST-y melbatkan pekerjaan tambahan untuk memetakan jalur URI ke  handler spesifik dan untuk mengimpor maksud permintaan HTTP request ke dalam skema. Banyak framework yang ada membuat tugas ini lebih mudah dilakukan. Namun demikian, saat ini, hal tersebut masih lebih mudah untuk mengekspos seperangkat method menggunakan SOAP daripada mengeksposnya menggunakan HTTP biasa.

Caching

Karena berbasis HTTP/Rest-ful API dapat dikonsumsi menggunakan request GET sederhana, server proxy/reverse-proxy dapat melakukan cache atas respon tersebut dengan mudah. Di sisi yang lain, request SOAP menggunakan POST dan membutuhkan request XML kompleks untuk dibangun yang akan membuat caching-respon terasa sulit.

KESIMPULAN

Dari penjelasan detail di atas dapat dikatakan bahwa SOAP tidak semudah itu, SOAP membutuhkan usaha implementasi yang lebih besar dan pengetahuan di sisi klien, sedangkan web service berbasis HTTP atau REST-API  membutuhkan implementasi yang lebih besar dan pengetahuan di sisi server. Adopsi API dapat meningkatkan lebih jauh lagi jika interface berbasis HTTP disediakan. Faktanya, HTTP berbasis API dengan respon XML/JSON mewakili yang terbaik dari kedua turunan dan mudah diimplementasikan dalam server semudah mengkonsumsi melalui server.

Untuk mengkonsumsi web service, kadang-kadang bingung mengimplementasikan mana yang lebih mudah. Sebagai contoh Google AdWords web service sangat sulit untuk dikonsumsi (dalam CF apapun), karena menggunakan header SOAP, dan sejumlah hal lain yang membuatnya sulit. Sebaliknya, web service REST Amazon kadangkala rumit untuk diuraikan (pase) karena sangat berulang, dan hasil schema dapat sedikit bervariasi sesuai dengan apa yang Anda cari.

Arsitektur mana yang Anda pilih, pastikan pilih yang termudah bagi developer untuk mengaksesnya, dan tersokumentasi dengan baik. Akhirnya ketika Anda meng-host layanan internet, hal tersebut adalah kompleksitas sisi klien yang paling penting untuk menarik klien untuk menggunakan web service Anda.

Web Service SOAP dan RESTful mempunyai filosofi yang berbeda. SOAP sesungguhnya sebuah protokol komputasi terdistribusi berbasis XML, dimana REST cenderung masih sangat baru, desain berbass web. Sebagai catatan SOAP tidak sekompleks yang dikatakan banyak sumber, SOAP dapat dikatakan kompleks ketika digunakan untuk banyak ekstensi.

Summary

Keuntungan SOAP

• bahasa, platform, dan transport agnostic
• dirancang untuk menangani lingkungan komputasi terdistribusi
• merupakan standar yang berlaku untuk web servis, sehingga mempunyai dukungan yang lebih baik dari standar yang lain (WSDL, WS-*) dan tools dari berbagai vendor
• built-in error handling (faults)
• extensibility

Kelemahan SOAP

• secara konseptual lebih sulit, lebih "heavy-weight" dibanding REST
• lebih "verbose" (membutuhkan lebih banyak pernyataan/kode program)
• sulit untuk dikembangkan, mebutuhkan tools

Keuntungan REST

• bahasa dan platform agnostic
• lebih sederhana/simpel untuk dikembangkan ketimbang SOAP
• mudah dipelajari, tidak bergantung pada tools
• ringkas, tidak membutuhkan layer pertukaran pesan (messaging) tambahan
• secara desain dan filosofi lebih dekat dengan web

Kelemahan REST

• Mengasumsi model point-to-point komunikasi - tidak dapat digunakan untuk lingkungan komputasi terdistribusi di mana pesan akan melalui satu atau lebih perantara
• Kurangnya dukungan standar untuk keamanan, kebijakan, keandalan pesan, dll, sehingga layanan yang mempunyai persyaratan lebih canggih lebih sulit untuk dikembangkan ("dipecahkan sendiri")
• Berkaitan dengan model transport HTTP

Sumber

http://greatgandhi.wordpress.com/2010/06/16/soap-vs-rest-%E2%80%93-the-best-webservice/

http://www.adityarizki.net/2012/06/web-service-soap-vs-rest-mana-yang-lebih-baik/

Satu Kata Rindu

Ketika rindu mengalahkan waktu

Mengoyak dada membuka luka

Menghambur serpih jiwa ke langit

Mendekap mata mengalir cinta

Dan jiwa kini bersatu dalam rindu

Mengepung aku dengan rasa haru

Bersua perlahan dan semakin menengah

Dan kita pun berharap menengadah

Ketika waktu kembali satukan kita

Meronta kata dalam jiwa

Namun tak bisa

Debur riuh dalam jiwa tak bersuara

~Kau torehkan waktu atas penantian kita, tahukah engkau…. atas waktu yang kubutuhkan untuk menemukan mu, kemudian jiwa meretak hancur berkeping saat kau berpaling. Tidaklah mengapa bagi jiwa yang merelakan mu untuk berbahagia, karena hanya Tuhan yang berhak membolak – balikan perasaan hambanya, lagi pula tak berhak seseorang menentukan kebahagiaan orang lain.

~ Sesaat kemudian kau berlari kembali pada ku, membawa luka yang kau dapat dari petualangan mu yang meninggalkan seberkas pedih saat kau lalu dari hidup ku. Lalu mengapa kau kembali, tak bisakah kau berhenti membuka luka. Dan akhirnya kau pun sadar juga, setelah sekian lama kau bertarung dengan waktu untuk mencari kebenaran hakiki.

Bukan Definisi Cinta

love

LOVE
waktu menggerakan ku
menghembuskan nafas cinta yang telah lalu
lalu aku hidup dalam pesona
menyudutkan ku pada satu rindu

bukan menggema
hanya satu kata hati yang tertunda
merapuhkan ku dalam ketidakpastian
cinta

andai waktu adalah ikatan masa
cukup getarkan saja dahan itu
lalu cinta dalam ketulusan itu tiba
lalu izinkan aku disana

~ ikhwan
Bukan waktu yang menghalangi kerinduan untuk berbagi, kadang keraguan terlanjur mendahului logika kita untuk memahami sedikit saja arti cinta itu. Saya tak akan mendefinisikan cinta, sekalipun telah dicoba hanya bisa dimengerti jika dirasakan. Hanya jiwa - jiwa yang tulus dan ikhlas berdiri tegak di tengah ketidakpastian mempertahankan keyakinannya akan sebuah kebahagiaan, bukan tentang dirinya tapi cinta itu sendiri.