Penggunaan fungsi $HTTP pada PHP

Hypertext Transfer Protocol (HTTP) adalah bagian kehidupan dari sebuah website. Ini digunakan setiap kali Anda mentransfer dokumen, atau membuat AJAX request. Tetapi yang mengejutkan HTTP relatif tidak dikenal di antara beberapa pengembang web.

Nội dung chính Show

Mengapa harus REST?
Memata-matai HTTP saat Bekerja
Kata Kerja HTTP
Mengklasifikasikan Metode HTTP
Representasi
Perpustakaan HTTP Client
Menyiapkan Contoh Aplikasi
Bagaimana Aplikasi Contoh Bekerja
Kode Respon
201 Created
400 Bad Request
404 Not Found
401 Unauthorized
405 Method Not Allowed
409 Conflict
500 Internal Server Error
Contoh Aplikasi Latihan
Kesimpulan

Pengenalan ini akan menunjukkan bagaimana prinsip-prinsip perangkat desain, yang dikenal sebagai REST, didukung HTTP, dan memungkinkan Anda untuk menyatukan kekuatan penuh dengan membangun tampilan, yang dapat digunakan di hampir semua perangkat atau sistem operasi.

Tutorial Terbitan Ulang

Setiap beberapa minggu, kami mengunjungi kembali beberapa post yang menjadi favorit pembaca kami dari seluruh riwayat situs. Tutorial ini pertama kali diterbitkan pada bulan November, 2010.

Mengapa harus REST?

REST adalah cara sederhana untuk mengatur interaksi antara sistem secara independen.

REST adalah cara sederhana untuk mengatur interaksi antara sistem secara independen. Sudah semakin populer sejak tahun 2005, dan menginspirasi layanan desain, seperti API Twitter. Hal ini disebabkan fakta bahwa REST memungkinkan Anda untuk berinteraksi dengan diatasnya minimal dengan klien yang beragam seperti ponsel dan situs-situs lain. Secara teori, REST tidak terikat dengan web, tapi itu hampir selalu dilaksanakan seperti itu, dan terinspirasi oleh HTTP. Akibatnya, REST dapat digunakan di mana HTTP pun bisa.

Alternatifnya adalah membangun kebiasaan yang relatif kompleks di atas HTTP. Seringkali, ini mengambil bentuk dari seluruh bahasa berbasis XML yang baru. Contoh yang paling terkenal adalah SOAP. Anda harus belajar yang sama sekali baru dari kebiasaan sebelumnya, tapi Anda tidak pernah menggunakan HTTP secara penuh. Karena REST telah terinspirasi oleh HTTP dan bermain untuk daya guna, itu adalah cara terbaik untuk belajar bagaimana HTTP bekerja.

Setelah gambaran awal, kami akan memeriksa setiap blok bagian HTTP: URL, kata kerja HTTP dan kode respon. Kami juga akan meninjau bagaimana menggunakannya dengan cara yang REST. Sepanjang jalan, kami akan mengilustrasikan teori dengan contoh aplikasi, yang mensimulasikan proses melacak data yang berhubungan dengan klien perusahaan melalui antarmuka web.

HTTP

HTTP adalah protokol yang memungkinkan untuk mengirimkan dokumen bolak-balik di web.

HTTP adalah protokol yang memungkinkan untuk mengirimkan dokumen bolak-balik di web. Protokol adalah seperangkat aturan yang menentukan pesan mana yang dapat ditukar, dan pesan balasan apa yang sesuai untuk orang lain. Protokol lain yang umum adalah POP3, yang mungkin Anda gunakan untuk mengambil email pada hard disk Anda.

Dalam HTTP, ada dua peran yang berbeda: server dan client. Secara umum, klien selalu memulai percakapan, dan server membalasnya. HTTP berbasis teks; yaitu, pesan yang pada adalah dasarnya bit teks, meskipun badan pesan juga dapat berisi media lainnya. Penggunaan teks memudahkan untuk memonitor pertukaran HTTP.

pesan HTTP terbuat dari header dan tubuh. Bagian tubuh seringnya dapat tetap kosong, berisi data yang Anda inginkan untuk mengirimkan melalui jaringan, untuk menggunakannya sesuai dengan petunjuk di header. Header berisi metadata, seperti pengkodean informasi; namun, dalam kasus permintaan, juga berisi metode HTTP yang penting. Dalam gaya REST, Anda akan menemukan bahwa data header sering lebih penting daripada tubuh.

Memata-matai HTTP saat Bekerja

Jika Anda menggunakan Alat Pengembang Chrome, atau Firefox dengan ekstensi terinstal Firebug, klik pada panel Net, dan atur ke enabled. Anda kemudian akan memiliki kemampuan untuk melihat rincian permintaan HTTP saat Anda menjelajah. Contoh:

Cara lain membantu untuk membiasakan diri dengan HTTP adalah dengan menggunakan klien khusus, seperti cURL.

Curl adalah alat baris perintah yang tersedia pada semua sistem operasi utama.

Setelah Curl Anda terinstal, ketik:

curl -v google.com

Ini akan menampilkan percakapan HTTP secara lengkap. Permintaan didahului oleh>, sedangkan tanggapan didahului oleh <.

URL

URL adalah bagaimana Anda mengidentifikasi hal-hal yang ingin Anda operasikan. Kita katakan bahwa setiap URL mengidentifikasi sumber daya. Ini adalah URL yang sama persis yang ditugaskan untuk halaman web. Bahkan, sebuah halaman web juga adalah jenis sumber daya. Mari kita contohkan yang lebih eksotis, dan mempertimbangkan contoh aplikasi kita, yang mengelola daftar klien perusahaan:

/clients

akan mengidentifikasi semua klien, sementara

/clients/jim

akan mengidentifikasi klien, bernama 'Jim', dengan asumsi bahwa ia adalah satu-satunya dengan nama itu.

Dalam contoh ini, kita biasanya tidak menyertakan nama host dalam URL, karena tidak relevan dari sudut pandang bagaimana antarmuka diatur. Namun demikian, nama host adalah penting untuk memastikan bahwa resource identifier unik di seluruh web. Kita sering mengatakan Anda mengirim permintaan untuk sumber daya ke host. Host termasuk dalam header secara terpisah dari jalan sumber daya, yang datang tepat di atas permintaan header:

GET /clients/jim HTTP/1.1

Host: example.com

Sumber daya terbaik dianggap sebagai kata benda. Sebagai contoh, berikut ini bukanlah REST:

/clients/add

Hal ini karena menggunakan URL untuk menggambarkan suatu tindakan. Ini adalah titik yang cukup mendasar dalam membedakan REST dari sistem non-REST.

Akhirnya, URL harus tepat seperti yang diperlukan; segala sesuatu yang diperlukan secara unik untuk mengidentifikasi sumber daya harus dalam URL. Anda tidak perlu memasukkan data mengidentifikasi sumber daya dalam permintaan. Dengan cara ini, URL bertindak sebagai peta lengkap dari semua data aplikasi yang Anda tangani.

Tapi bagaimana Anda menentukan tindakan yang spesifik? Misalnya, bagaimana Anda tahu bahwa klien baru yang Anda rekam itu baru dibuat bukan diambil? Itu adalah di mana kata kerja HTTP ikut bermain.

Kata Kerja HTTP

Setiap permintaan kata kerja atau metode HTTP tertentu, dalam permintaan header. Ini adalah hal pertama dari semua kata dalam permintaan header. Contohnya,

GET / HTTP/1.1

berarti metode GET sedang digunakan, sementara

DELETE /clients/anne HTTP/1.1

berarti metode DELETE sedang digunakan.

Kata kerja HTTP memberitahu server apa yang harus dilakukan dengan data yang diidentifikasi oleh URL.

Kata kerja HTTP memberitahu server apa yang harus dilakukan dengan data yang diidentifikasi oleh URL. Permintaan opsional dapat berisi informasi tambahan di dalam tubuhnya, yang mungkin diperlukan untuk melakukan operasi - misalnya, data yang Anda ingin simpan dengan sumber daya. Anda dapat menyediakan data ini dalam Curl dengan opsi -d.

Jika Anda pernah membuat bentuk HTML, Anda akan akrab dengan dua dari kata kerja HTTP dan yang paling penting: GET dan POST. Tetapi ada jauh lebih banyak kata kerja HTTP yang tersedia. Yang paling penting untuk membangun REST API adalah GET, POST, PUT dan DELETE. Metode lain yang tersedia, seperti HEAD dan OPTIONS, tetapi mereka lebih jarang digunakan (jika Anda ingin tahu tentang semua metode HTTP lainnya, sumber resmi IETF).

GET

GET adalah jenis yang paling sederhana dari metode permintaan HTTP; salah satu yang browser gunakan setiap kali Anda mengklik link atau mengetik URL ke address bar. Ini menginstruksikan server untuk mengirimkan data yang diidentifikasi oleh URL ke klien. Data tidak pernah diubah pada sisi server sebagai akibat dari permintaan GET. Dalam hal ini, permintaan GET adalah read-only, tapi tentu saja, setelah klien menerima data, ia bebas untuk melakukan operasi apapun dengan sisi itu sendiri - misalnya, format untuk tampilan.

PUT

Permintaan PUT digunakan ketika Anda ingin membuat atau memperbarui sumber daya yang diidentifikasi oleh URL. Contoh,

PUT /clients/robin

memungkinkan membuat klien, bernama Robin pada server. Anda akan melihat bahwa REST adalah benar-benar backend agnostik; tidak ada dalam permintaan yang menginformasikan server bagaimana data harus dibuat - hanya yang seharusnya. Hal ini memungkinkan Anda dengan mudah untuk menukar teknologi backend jika perlu dimunculkan. permintaan PUT berisi data untuk digunakan dalam memperbarui atau menciptakan sumber daya di dalam tubuh. Dalam Curl, Anda dapat menambahkan data ke permintaan dengan switch -d.

curl -v -X PUT -d "some text"

DELETE

DELETE harus melakukan sebaliknya dari PUT; harus digunakan bila Anda ingin menghapus sumber daya yang diidentifikasi oleh permintaan URL.

curl -v -X DELETE /clients/anne

Ini akan menghapus semua data yang terkait dengan sumber daya, diidentifikasi dengan /clients/anne.

POST

POST digunakan ketika pengolahan Anda ingin terjadi di server harus diulang, jika permintaan POST diulang (yaitu, mereka tidak idempotent, lebih di bawahnya). Selain itu, permintaan POST harus menyebabkan pengolahan tubuh permintaan sebagai bawahan dari URL yang Anda terbitkan.

Sederhananya:

POST /clients/

Seharusnya tidak menyebabkan sumber daya di /clients/, termodifikasi sendiri, tetapi sumber daya yang URL dimulai dengan /clients/. Misalnya, bisa menambahkan klien baru ke dalam daftar, dengan id yang dihasilkan oleh server.

/clients/some-unique-id

Permintaan PUT digunakan lebih mudah dibanding permintaan POST, dan sebaliknya. Beberapa sistem menggunakan hanya satu, beberapa penggunaan POST untuk membuat operasi, dan PUT untuk operasi update (karena dengan permintaan PUT Anda selalu menyediakan URL lengkap), bahkan ada yang menggunakan POST untuk memperbaruhi dan PUT untuk menciptakan.

Seringkali, permintaan POST digunakan untuk memicu operasi pada server, yang tidak cocok dengan paradigma Create/Update/Delete; tapi ini, bagaimanapun ini berada diluar lingkup REST. Dalam contoh kita, kita akan tetap bersama PUT sepanjang jalan.

Mengklasifikasikan Metode HTTP

Metode yang aman dan tidak aman:

metode yang aman adalah mereka yang tidak pernah memodifikasi sumber daya. Satu-satunya metode yang aman, dari empat yang tercantum di atas, adalah GET. Yang lainnya adalah tidak aman, karena mereka dapat menyebabkan modifikasi dari aslinya.

Metode Idempotent:

Metode ini mencapai hasil yang sama, tidak peduli berapa kali permintaan diulang: yaitu GET, PUT, dan DELETE. Satu-satunya metode non idempotent adalah POST. PUT dan DELETE sedang dipertimbangkan idempotent mungkin mengejutkan, meskipun, itu, pada kenyataannya, cukup mudah untuk dijelaskan: mengulangi metode PUT dengan tepat tubuh yang sama harus memodifikasi sumber daya dengan cara yang tetap identik dengan yang dijelaskan dalam permintaan PUT sebelumnya: tidak akan ada perubahan! Demikian pula, tidak masuk akal untuk menghapus sumber daya dua kali. Hal berikut bahwa tidak peduli berapa kali permintaan PUT atau DELETE diulang, hasilnya harus sama seolah-olah itu hanya dilakukan sekali.

Ingat: Anda adalah programmer, yang akhirnya memutuskan apa yang terjadi ketika sebuah metode HTTP tertentu digunakan. Tidak ada yang melekat pada implementasi HTTP secara otomatis akan menyebabkan sumber daya yang akan dibuat, terdaftar, dihapus, atau diperbarui. Anda harus berhati-hati untuk menerapkan protokol HTTP dengan benar dan menegakkan semantik Anda sendiri.

Representasi

HTTP client dan HTTP server melakukan pertukaran informasi tentang sumber daya dan diidentifikasi oleh URL.

Kita dapat menyimpulkan apa yang telah kita pelajari sejauh ini dengan cara berikut: HTTP client dan HTTP server merupakan pertukaran informasi tentang sumber daya dan diidentifikasi oleh URL.

Kita mengatakan bahwa permintaan dan respon mengandung representasi dari sumber daya. Dengan representasi, yang kita maksudkan informasi, dalam format tertentu, tentang keadaan sumber daya atau bagaimana bahwa keadaan harus berada di masa depan. Header dan tubuh keduanya adalah bagian dari representasi.

Header HTTP, yang mengandung metadata, secara ketat didefinisikan oleh spesifikasi HTTP; mereka hanya dapat berisi teks biasa, dan harus diformat dengan cara tertentu.

Tubuh dapat berisi data dalam format apapun, dan ini adalah di mana kekuatan HTTP benar-benar bersinar. Anda tahu bahwa Anda dapat mengirim teks biasa, gambar, HTML, dan XML dalam berbagai bahasa manusia. Melalui permintaan metadata atau URL yang berbeda, Anda dapat memilih antara representasi yang berbeda untuk sumber daya yang sama. Sebagai contoh, Anda mungkin mengirim halaman web ke browser dan JSON untuk aplikasi.

Respon HTTP harus menentukan jenis konten dari tubuh. Hal ini dilakukan di header, dibagian Content-Type; contohnya:

Content/Type: application/json

Untuk mempermudah, contoh aplikasi kita hanya mengirim JSON bolak-balik, tetapi aplikasi harus berarsitektur sedemikian rupa bahwa Anda dapat dengan mudah mengubah format data, untuk menyesuaikan untuk klien yang berbeda atau preferensi pengguna.

Perpustakaan HTTP Client

Curl adalah, lebih sering daripada tidak, solusi pilihan untuk HTTP client bagi pengembang PHP.

Untuk bereksperimen dengan metode permintaan yang berbeda, Anda perlu klien, yang memungkinkan Anda untuk menentukan metode mana yang digunakan. Sayangnya, bentuk HTML tidak sesuai dengan tagihan, karena mereka hanya memungkinkan Anda untuk membuat permintaan GET dan POST. Dalam kehidupan nyata, API diakses dalam pemrograman melalui aplikasi klien terpisah, atau melalui JavaScript di browser.

Ini adalah alasan mengapa, selain server, adalah penting untuk memiliki kemampuan HTTP client yang baik dalam bahasa pemrograman pilihan Anda.

Perpustakaan HTTP client yang sangat populer, sekali lagi, cURL. Anda sudah mengenal dengan beberapa perintah Curl dari dalam tutorial ini sebelumnya. cURL meliputi program baris perintah mandiri, dan perpustakaan yang dapat digunakan oleh berbagai bahasa pemrograman. Secara khusus, cURL lebih sering daripada tidak, solusi pilihan HTTP client bagi pengembang PHP. Bahasa lainnya, seperti Python, menawarkan perpustakaan HTTP client lebih asli.

Menyiapkan Contoh Aplikasi

Saya ingin mengekspos fungsi tingkat rendah sebanyak mungkin.

Contoh aplikasi PHP kita sangat barebone. Saya ingin mengekspos fungsi tingkat rendah sebanyak mungkin, tanpa sihir framework. Saya juga tidak ingin menggunakan API nyata, seperti Twitter, karena mereka dapat merubah subjek tiba-tiba, Anda perlu mengatur otentikasi, yang rumit, dan yang jelas, Anda tidak bisa belajar implementasinya.

Untuk menjalankan aplikasi contoh, Anda akan perlu menginstal PHP5 dan web server, dengan beberapa mekanisme untuk menjalankan PHP. Versi saat ini harus minimal versi 5.2 untuk memiliki akses ke fungsi json_encode() dan json_decode().

Adapun server, pilihan yang paling umum adalah masih menggunakan Apache dengan mod_php, tetapi Anda bebas untuk menggunakan alternatif yang menurut Anda lebih nyaman. Ini adalah contoh konfigurasi Apache, yang berisi cara menulis ulang aturan yang membantu Anda untuk mngatur aplikasi dengan cepat. Semua permintaan untuk setiap URL, dimulai dengan /clients/, harus dialihkan ke file server.php kita.

Dalam Apache, Anda perlu mengaktifkan mod_rewrite dan menempatkan konfigurasi mod_rewrite yang disediakandi suatu tempat di konfigurasi Apache Anda, atau berkas .htacess Anda. Dengan cara ini, server.php akan menanggapi semua permintaan yang datang dari server. Hal yang sama harus dicapai dengan Nginx, atau mana server alternatif yang bisa Anda putuskan untuk menggunakan yang mana.

Bagaimana Aplikasi Contoh Bekerja

Ada dua kunci untuk memproses permintaan dengan cara REST. Kunci pertama adalah untuk memulai pengolahan yang berbeda, tergantung pada metode HTTP, bahkan apabila URL sama. Di PHP, ada variabel dalam $ _SERVER di dalam globay array, yang menentukan metode yang telah digunakan untuk membuat permintaan:

$_SERVER['REQUEST_METHOD']

Variabel ini berisi metode nama sebagai string, misalnya 'GET', 'PUT', dan sebagainya.

Kunci lainnya adalah untuk mengetahui URL telah diminta. Untuk melakukan hal ini, kita menggunakan variabel PHP standar lain:

$_SERVER['REQUEST_URI']

Variabel ini berisi URL dimulai dengan garis miring pertama. Misalnya, jika nama hostnya adalah 'example.com', 'http://example.com/' akan kembali '/', sementara 'http://example.com/test/' akan kembali '/test/'.

Ok pertama mencoba untuk menentukan URL yang telah disebut. Kita mencoba URL yang dimulai dengan 'clients'. Semua lainnya tidak valid.

$resource = array_shift($paths);

if ($resource == 'clients') {
    $name = array_shift($paths);

    if (empty($name)) {
        $this->handle_base($method);
    } else {
        $this->handle_name($method, $name);
    }

} else {
    // We only handle resources under 'clients'
    header('HTTP/1.1 404 Not Found');
}

Kita memiliki dua hasil kemungkinan:

sumber daya adalah klien, dalam hal ini, kita kembali ke daftar lengkap
Ini adalah identifier lanjutan

Jika ada identifier lebih lanjut, kita menganggap itu adalah nama klien, dan, sekali lagi, teruskan ke fungsi yang berbeda, tergantung pada metode. Kami menggunakan pernyataan switch, yang harus dihindari dalam aplikasi nyata:

switch($method) {
  case 'PUT':
      $this->create_contact($name);
      break;

  case 'DELETE':
      $this->delete_contact($name);
      break;

  case 'GET':
      $this->display_contact($name);
      break;

  default:
      header('HTTP/1.1 405 Method Not Allowed');
      header('Allow: GET, PUT, DELETE');
      break;
  }

Kode Respon

Standarisasi kode respon HTTP adalah cara untuk menginformasikan klien tentang hasil permintaannya.

Anda mungkin telah memperhatikan bahwa contoh aplikasi menggunakan header() PHP, melewati beberapa string tampak aneh sebagai argumen. Fungsi header() mencetak headers HTTP dan memastikan bahwa mereka diformat dengan tepat. Header harus menjadi hal pertama pada respon, sehingga Anda tidak harus menambah apa pun sebelum Anda selesai dengan header. Kadang-kadang, HTTP server Anda mungkin dikonfigurasi untuk menambahkan header lain, selain yang Anda tentukan dalam kode Anda.

Header mengandung semua jenis informasi meta; misalnya, pengkodean teks yang digunakan di tubuh pesan atau jenis body konten MIME. Dalam hal ini, kita secara eksplisit menentukan kode respon HTTP. kode respon HTTP adalah cara standarisasi untuk menginformasikan klien tentang hasil permintaannya. Secara default, PHP membalas kode respon 200, yang berarti bahwa respon berhasil.

Server harus membalas dengan kode respon HTTP yang paling tepat; dengan cara ini, klien dapat mencoba untuk memperbaiki kesalahannya, dengan asumsi ada kesalahan. Kebanyakan orang akrab dengan kode respon umum 404 Not Found, namun, ada lebih banyak respon yang tersedia untuk menyesuaikan di berbagai macam situasi.

Perlu diingat bahwa arti kode respon HTTP yang tidak tepat; ini merupakan konsekuensi dari HTTP itu sendiri yang menjadi agak generik. Anda harus berusaha untuk menggunakan kode respon yang paling sesuai dengan situasi yang dihadapi. Bisa dikatakan, jangan khawatir terlalu banyak jika Anda tidak dapat menemukan sesuatu yang tepat atau cocok.

Berikut adalah beberapa kode respon HTTP, yang sering digunakan ketika menggunakan REST:

200 OK

Respon ini menunjukkan bahwa permintaan berhasil dibuat.

201 Created

Hal ini menunjukkan permintaan berhasil dan sumber daya telah dibuat. Hal ini digunakan untuk mengkonfirmasi keberhasilan suatu PUT atau permintaan POST.

400 Bad Request

Permintaan jelek. Hal ini terjadi terutama dengan POST dan permintaan PUT, ketika data tidak lulus validasi, atau dalam format yang salah.

404 Not Found

Respon ini menunjukkan bahwa sumber daya yang diperlukan tidak dapat ditemukan. Hal ini umumnya dikembalikan ke semua permintaan yang menunjuk ke sebuah URL tanpa sumber daya yang sesuai.

401 Unauthorized

Kesalahan ini menunjukkan bahwa Anda perlu melakukan otentikasi sebelum mengakses sumber daya.

405 Method Not Allowed

Metode HTTP yang digunakan tidak didukung untuk sumber daya ini.

409 Conflict

Hal ini menunjukkan adanya konflik. Misalnya, Anda menggunakan permintaan PUT untuk menciptakan sumber daya yang sama dua kali.

500 Internal Server Error

Ketika semuanya gagal; umumnya, respon 500 digunakan ketika memproses kegagalan karena keadaan yang tak terduga pada sisi server, yang menyebabkan server menampilkan pesan error.

Contoh Aplikasi Latihan

Mari kita mulai denganmengambil informasi sederhana dari aplikasi Kita ingin rincian klien, 'jim', jadi mari kita mengirim permintaan sederhana GET ke URL untuk sumber daya ini:

curl -v http://localhost:80/clients/jim

Ini akan menampilkan pesan header lengkap. Baris terakhir dalam respon akan isi pesan; dalam hal ini, itu akan menjadi JSON yang mengandung alamat Jim (ingat bahwa menghilangkan nama metode akan menghasilkan permintaan GET, juga mengganti localhost: 80 dengan nama server dan port yang Anda gunakan).

Berikutnya, kita dapat memperoleh untuk semua informasi klien sekaligus:

curl -v http://localhost:80/clients/

Untuk membuat klien baru, dengan nama Paul ...

curl -v -X PUT http://localhost:80/clients/paul -d '{"address":"Sunset Boulevard" }

dan sekarang Anda akan menerima semua daftar klien yang berisi kata Paul sebagai konfirmasi.

Akhirnya, untuk menghapus klien:

curl -v -X DELETE http://localhost:80/clients/anne

Anda akan menemukan kembali bahwa JSON tidak lagi berisi data apapun tentang Anne.

Jika Anda mencoba untuk mengambil klien yang tidak ada, misalnya:

curl -v http://localhost:80/clients/jerry

Anda akan mendapatkan error 404, sementara, jika Anda mencoba untuk membuat klien yang sudah ada:

curl -v -X PUT http://localhost:80/clients/anne

Anda malah akan menerima error 409.

Kesimpulan

Secara umum, sedikit asumsi diluar HTTP yang Anda buat, semakin baik.

Sangat penting untuk diingat bahwa HTTP dikonsep untuk berkomunikasi antar sistem, yang mana tidak ada yang dibagi selain memahami tentang protokol. Secara umum, semakin sedikit asums diluar HTTP yang Anda buat, semakin baik: ini memungkinkan jangkauan program lebih lebar dan perangkat untuk mengakses API Anda.

Saya menggunakan PHP dalam tutorial ini, karena kemungkinan besar itu bahasa yang paling akrab bagi pembaca Nettuts+. Itu berarti, PHP, meskipun dirancang untuk web, mungkin bukan bahasa terbaik untuk digunakan saat bekerja dengan cara REST, karena menangani permintaan PUT dengan cara yang sama sekali berbeda dari GET dan POST.

Di luar PHP, Anda mungkin akan mempertimbangkan hal berikut:

Berbagai Ruby frameworks (Rails dan Sinatra)
Terdapat dukungan REST yang sangat baik pada Python. Sederhananya Django dan WebOb, atau Werkzeug harus bekerja
node.js memiliki dukungan yang sangat baik untuk REST

Di antara aplikasi yang mencoba untuk mematuhi prinsip REST, contoh klasiknya adalah Atom Publishing Protocol, meskipun itu benar-benar tidak terlalu sering digunakan dalam praktek. Untuk aplikasi modern, yang dibangun menggunakan filosofi HTTP sepenuhnya, bisa dilihat Apache CouchDB.

Selamat bersenang-senang!