Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. WordPress

Memperkenalkan WP REST API

by
Read Time:15 minsLanguages:
This post is part of a series called Introducing the WP REST API.
WP REST API: Setting Up and Using Basic Authentication

Indonesian (Bahasa Indonesia) translation by Hasannudin Amin (you can also view the original English article)

Dengan dimulainya pada tahun 2003, WordPress telah berkembang dari sekedar platform blogging ke sistem pengelolaan konten yang matang. Selama beberapa tahun terakhir ini, telah cukup matang untuk memenuhi kebutuhan sebagian besar pemirsa online dan inilah alasannya bahwa lebih dari 20% web menggunakan wordpress hari ini.

Dengan banyak fitur baru yang ditambahkan ke WordPress, salah satu tambahan terbaru adalah REST API yang memungkinkan aplikasi dan platform lain berinteraksi dengan WordPress. Ini adalah tambahan revolusioner yang akan membantu pengembang membangun aplikasi kustom dan sistem terintegrasi dengan WordPress. Karena menyediakan kemampuan untuk menambahkan dan mengambil konten dari klien atau situs lain, tanpa perlu menginstal WordPress di situs itu, WordPress memungkinkan untuk digunakan dengan bahasa pemrograman atau platform apa pun.

Dalam seri multi-bagian ini, kita akan melihat WP REST API dan bagaimana penggunaannya untuk menciptakan pengalaman pengguna yang mungkin tidak mungkin atau paling tidak, sulit dilakukan dengan WordPress. Pertama-tama, kita akan melihat konsep dasar termasuk REST dan JSON, lalu jelajahi opsi yang tersedia kepada kita melalui WP REST API.

Berikut adalah beberapa sumber yang saya anggap berguna untuk konsep dasar termasuk HTTP, REST, dan JSON. Saya sangat menyarankan Anda untuk melihat mereka jika Anda belum melakukannya:

Sebelum kita memulai dengan topik kita, mari kita lihat secara singkat apa sebenarnya arsitektur REST dan juga terbiasa dengan terminologi yang umum.

Kembali Dengan REST

Untuk memulai dengan topik ini, mari kita lihat arsitektur REST (Representational State Transfer) dan beberapa konsepnya yang paling umum. Memahami mereka adalah penting saat mengembangkan aplikasi dengan menggunakan gaya arsitektur REST.

REST adalah gaya arsitektur yang membantu menciptakan dan mengatur sistem terdistribusi. Ini menggambarkan web sebagai aplikasi hypermedia terdistribusi yang sumber datanya terhubung dengan bertukar ke representasi kondisi resource (sumber daya).

Resource adalah blok bangunan utama dari arsitektur REST. Sebenarnya, ini adalah blok bangunan utama dari web itu sendiri sejauh web kadang-kadang disebut sebagai "resource-oriented".

Ketika berbicara tentang WordPress, sumber daya ini adalah entitas terpisah seperti posts, pages, comments, users, custom post types dll. Untuk berinteraksi dengan sumber daya, URI (Uniform Resource Identifier) digunakan, dan seperti namanya, ini adalah pengenal sumber daya (resource).

Layanan RESTful memperlakukan URI sebagai cara utama untuk mengatasi sumber daya yang mendasarinya. Sumber daya (resource) ini mungkin memiliki beberapa representasi. Misalnya, file gambar mungkin tersedia dalam format .JPG, .GIF, atau .PNG. Hubungan antara sumber daya dan URI adalah satu-ke-banyak. URI hanya bisa menunjuk pada satu sumber daya spesifik namun sumber daya mungkin memiliki lebih dari satu URI.

Daftar semua sumber daya yang saat ini didukung oleh WP REST API adalah sebagai berikut:

  • Posts
  • Pages
  • Media
  • Custom Post Types
  • Post Meta
  • Revisions
  • Comments
  • Terms
  • Users

Kita dapat melakukan tindakan yang berbeda pada sumber daya ini menggunakan HTTP verb.

HTTP Verb

REST API pada dasarnya memungkinkan untuk melakukan operasi CRUD (Create Read Update Delete) pada sumber daya yang menggunakan HTTP. Untuk tujuan ini, REST menggunakan seperangkat HTTP verb request terbatas sebagai berikut:

  1. GET: Digunakan untuk membaca atau mengambil sumber daya
  2. POST: Digunakan untuk membuat resource baru
  3. PUT: Digunakan untuk mengupdate resource
  4. DELETE: Digunakan untuk menghapus resource
  5. HEAD: Digunakan untuk memeriksa apakah ada sumber daya tanpa mengembalikan representasinya
  6. OPTIONS: Digunakan untuk mengambil semua verba yang didukung oleh sumber daya

Dalam layanan RESTful, verb ini memiliki makna yang jelas. Empat verb pertama dalam daftar di atas adalah bagian dari tindakan CRUD yaitu mereka mengambil, membuat, memperbarui, dan menghapus entitas. Dua verb terakhir membantu klien dalam menentukan apakah sumber daya ada dan HTTP verb apa yang tersedia untuk melakukan operasi lebih lanjut.

Permintaan GET mengambil informasi dan idempotent yaitu klien dapat memanggilnya berkali-kali namun tidak akan mempengaruhi keadaan sumber daya.

Untuk mendapatkan semua posting menggunakan WP REST API, kami menggunakan endpoint berikut:

Endpoint di atas akan menampilkan koleksi semua entitas pos.

Ketika endpoint berikut dipicu, ia mengembalikan entitas tertentu yaitu sebuah pos yang memiliki id 100:

Permintaan POST membuat entitas baru dan permintaan PUT menggantikan entitas tersebut dengan versi baru.

Permintaan POST berikut dapat digunakan untuk membuat posting baru (mengirim seluruh badan permintaan yang akan kita lihat di bagian akhir seri) menggunakan WP REST API:

Dan permintaan PUT berikut akan memperbarui posting yang memiliki id 100:

Permintaan DELETE akan menghapus sumber daya dari sistem. Jenis permintaan ini, bersama dengan permintaan PUT dapat diulang, artinya memanggil metode ini akan memiliki efek yang sama pada sistem. Misalnya, jika Anda memanggil permintaan PUT berkali-kali pada sumber daya (dengan argumen yang sama), hasilnya akan sama. Hal yang sama berlaku untuk permintaan DELETE. Menghapus sumber daya beberapa kali akan memiliki efek yang sama yaitu sumber daya akan dihapus (atau kesalahan akan dikembalikan jika sumber daya yang telah dihapus).

Selain tindakan CRUD ini, layanan RESful menyediakan dua verb lagi yaitu OPTIONS dan HEADS. Verb ini berguna saat klien perlu memeriksa sumber daya apa yang tersedia di sistem dan tindakan apa yang mereka dukung, sehingga memberikan cara mendokumentasikan sendiri bagi klien untuk lebih jauh menjelajahi sistem dan melakukan tindakan. Kita akan melihat kedua metode ini dalam tindakan nanti dalam tutorial ini.

Selengkapnya Tentang Route dan Endpoint

Perhatikan bahwa pada contoh pertama di atas, kami menggunakan endpoint berikut:

Endpoint adalah fungsi yang tersedia melalui API dan mereka melakukan beberapa tindakan seperti mengambil posting (yang sedang kita lakukan di atas), membuat pengguna baru, atau memperbarui postingan meta. Sebagai alternatif, kita dapat mengatakan bahwa endpoint memicu metode yang melakukan tugas tertentu. Endpoint ini bergantung pada kata kerja HTTP yang terkait dengannya. Pada contoh di atas, kita menggunakan verb GET untuk mengambil semua posting.

Route untuk endpoint di atas adalah sebagai berikut:

Route pada dasarnya adalah sebuah nama untuk mengakses titik akhir. Route dapat memiliki beberapa endpoint berdasarkan verba HTTP. Jadi route di atas memiliki endpoint berikut untuk membuat posting baru:

Titik akhir ini, bila dipicu dengan parameter yang diberikan, akan membuat entitas pos baru.

Pertimbangkan rute berikut ini:

Rute ini menunjuk ke entitas Pos yang memiliki id 100. Ini memiliki tiga endpoint berikut:

  1. GET wp/v2/posts/100: Yang bisa digunakan untuk mengambil postingan yang memiliki id 100. Ini memicu metode get_item().
  2. PUT wp/v2/posts/100: Bisa digunakan untuk mengupdate post yang memiliki id 100. Ini memicu metode update_item().
  3.  Ini menghapus posting yang memiliki id 100. Ini memicu metode delete_item().

Kita akan belajar lebih banyak tentang internal WP REST API, struktur kelasnya, dan metode internal di bagian akhir seri ini.

Mari sekarang segarkan pengetahuan kita tentang beberapa kode respons HTTP yang umum dan apa artinya.

Kode tanggapan HTTP

Server merespons permintaan dengan mengembalikan respons yang berisi kode status HTTP. Kode-kode ini adalah angka dengan makna yang telah ditentukan sebelumnya yang terkait dengannya. Misalnya, siapa pun yang menggunakan web akan terbiasa dengan kode status 404 yang merangkum sumber daya yang dicari pengguna, tidak ditemukan.

Respon server juga tergantung pada jenis kata kerja HTTP atau metode yang kita gunakan dalam permintaan yang dikirim, seperti yang akan kita lihat selanjutnya.

Berikut adalah beberapa kode respons HTTP yang umum beserta maknanya, yang akan kita hadapi saat bekerja dengan WP REST API dan maknanya:

  • 200 ‒ OK: Berarti permintaan tersebut telah selesai dengan sukses dan server telah mengembalikan tanggapannya. Biasanya dikembalikan setelah permintaan GET berhasil.
  • 201 - Created: Biasanya dikembalikan setelah permintaan POST berhasil. Ringkas bahwa sumber daya telah diciptakan.
  • 400 - Bad Request: Ini dikembalikan dari server saat permintaan dikirim dengan beberapa parameter yang hilang atau tidak valid. Biasanya dikembalikan sebagai tanggapan atas permintaan POST atau PUT.
  • 401 - Unauthorized: Berarti pengguna tersebut tidak berwenang melakukan tindakan tertentu. Misalnya, pengguna mencoba membuat atau menghapus sumber daya tanpa memberikan kredensial otentikasi.
  • 403 - Forbidden: Berarti server mengerti permintaan namun menolak untuk menyelesaikannya karena adanya otentikasi. Ini terjadi ketika pengguna memberikan kredensial otentikasi namun tidak memiliki hak yang cukup untuk melakukan tindakan tersebut.
  • 404 - Not Found: Yang paling terkenal dari semua kode status. Merangkum sumber daya yang dicari pengguna, tidak ditemukan.
  • 405 - Method not Allowed: Berarti bahwa kata kerja HTTP yang disertakan dalam permintaan tidak didukung oleh sumber daya. Contohnya mungkin pengguna mencoba memperbarui sumber daya yang read-only.
  • 410 - Gone: Berarti sumber daya telah dipindahkan ke lokasi lain. Contohnya mungkin mencoba menghapus sumber daya yang telah dihapus yang telah dipindahkan ke sampah.
  • 500 - Internal Server Error: Ini dikembalikan saat server menemukan kondisi yang tidak terduga dan tidak menyelesaikan permintaan.
  • 501 - Not Implemented: Berarti server tidak mendukung fungsinya untuk menyelesaikan permintaan. Biasanya terjadi ketika server menerima metode permintaan yang tidak dikenali.

Kita akan melihat HTTP verb dan kode tanggapan ini lebih dekat saat kita benar-benar mulai bekerja dengan API. Tapi sebelum itu, mari kita lihat alasan penggunaan API REST dengan WordPress dan kelebihan yang diberikannya kepada pengembang dan pengguna. Lagi pula, saya ingin Anda benar-benar tertarik untuk mengikuti saya sepanjang seri ini.

Mengapa Menggunakan JSON REST API untuk WordPress?

REST dan JSON bersama-sama menyediakan mekanisme untuk membuat aplikasi yang hebat dengan menggunakan WordPress back-end. Contoh paling utama adalah aplikasi seluler yang memerlukan pertukaran data antara klien (perangkat) dan server. Dengan mengingat keterbatasan bandwidth saat menggunakan data seluler, JSON menyediakan alternatif ringan untuk solusi berbasis XML.

Karena JSON adalah format berbasis teks untuk menyimpan data, JSON dapat digunakan secara mulus dengan sebagian besar bahasa pemrograman. Oleh karena itu JSON berfungsi sebagai konektor global saat bertukar data antar platform yang berbeda yang sama-sama dapat dibaca oleh kedua mesin dan manusia.

Dengan penggunaan API seperti yang sedang dibahas, konten situs WordPress Anda tidak terbatas pada dirinya sendiri saja, namun bisa diakses oleh situs dan klien lain. Karena API menampilkan beberapa bagian fungsi internal, klien jarak jauh dapat berinteraksi dengan situs Anda untuk memperbarui atau membuat konten baru. Ini juga memungkinkan untuk mengambil beberapa konten dari situs WordPress yang ada dan menampilkannya di beberapa situs lain.

Dengan munculnya framework JavaScript sisi klien seperti Angular, Backbone atau Ember, sekarang dimungkinkan untuk menggunakan salah satu dari ini untuk menciptakan pengalaman pengguna yang kaya sambil tetap menggunakan WordPress back-end.

Dengan apa yang sudah dibicirakan sebelumnya, beberapa kasus penggunaan yang mungkin untuk WP REST API adalah:

  • Aplikasi seluler
  • Panel admin khusus untuk WordPress
  • Aplikasi Laman Tunggal (SPA)
  • Integrasi dengan platform sisi server lainnya (seperti Ruby, .NET, dan Django dll.)
  • dan banyak lagi…

Ini benar-benar membuka dunia baru kemungkinan di mana satu-satunya batasan adalah imajinasi seseorang.

Sejarah singkat JSON REST API di WordPress

Sebelum API REST berbasis JSON, API yang digunakan untuk berinteraksi dari jarak jauh dengan WordPress adalah API XML-RPC yang masih merupakan bagian dari inti WordPress. Masalah dengan XML adalah bahwa hal itu tidak ringan seperti format JSON dan penguraiannya tidak efisien. Traversing XML juga salah satu hal yang bikin sakit kepala, sementara traversing objek JSON semudah menangani objek JavaScript asli.

Plugin API REST yang pertama yang diperkenalkan untuk WordPress adalah JSON API yang dirilis pada tahun 2009. Dibangun di The Museum of Modern Art untuk blog mereka Inside/Out. Front-end blog ini didukung oleh Ruby on Rails, jadi untuk mengambil posting dari dan menambahkan komentar ke backend WordPress, sebuah API dikembangkan. Plugin ini menyediakan antarmuka untuk mengambil konten dan mengirimkan komentar ke backend WP. Meski tidak diperbarui lebih dari dua tahun, plugin ini masih ada di repositori resmi dan siap di ambil.

Selain plugin JSON API, WordPress.com telah menyediakan JSON API melalui plugin JetPack.

WP REST API, seperti yang kita ketahui sekarang adalah plugin fitur yang diusulkan oleh Ryan McCue sebagai bagian dari GsoC (Google Summer of Code) 2013. Ini belum disertakan (sepenuhnya) di inti WordPress dalam rilis mendatang. Versi 2.0 plugin saat ini berada dalam status beta dan sebagian disertakan dalam inti WordPress di versi 4.4. Ini adalah proyek berbasis komunitas yang dipimpin oleh Ryan McCue dan Rachel Baker. Halaman repositori resmi plugin terletak di GitHub dan dokumentasi resmi dapat ditemukan di situsnya.

Status Saat Ini dari WP REST API

Seperti disebutkan di atas bahwa WP REST API saat ini dalam keadaan sebagai plugin dan sedang dikembangkan secara aktif di GitHub. Ini sebagian telah disertakan dalam inti WordPress di versi 4.4 dan Ryan telah menjelaskan rencananya dalam proposal penggabungannya di WordPress.org.

Menurut proposal penggabungan, WP REST API akan digabungkan ke dalam inti WP dalam dua tahap seperti yang dijelaskan di bawah ini:

Kode Infrastruktur Penggabungan

Menurut proposal, pada tahap awal, hanya kode tingkat infrastruktur yang akan digabungkan ke dalam inti WP di rilis 4.4. Kode infrastruktur ini adalah basis sebenarnya dari WP REST API karena menyertakan serialisasi / deserialization JSON, tautan, embedding, dan yang paling penting - lapisan perutean yang mendorong API. Kode ini tidak termasuk endpoint dan kelas kontroler mereka, namun ini memberikan dasar untuk membangun API di dalam WordPress.

Pada saat penulisan, status ini telah selesai dan kode infrastrukturnya telah digabungkan dalam inti WordPress di versi 4.4.

Endpoints Merge

Titik akhir untuk posting, halaman, pengguna, dan taksonomi dll akan digabungkan dalam inti WP dalam rilis 4.5, yaitu satu rilis lebih lambat daripada penggabungan kode infrastruktur. Titik akhir adalah apa yang membuat API berguna bagi klien umum. Mereka mencakup banyak kompleksitas termasuk memetakan data eksternal dalam format JSON ke tipe data asli WordPress, dan sebaliknya. Mereka menjelaskan kode dua-tiga API itu sendiri dengan sekitar 5.500 baris.

Strateginya di sini adalah untuk membangun kepercayaan pengembang di API dengan terlebih dahulu memberikan kode infrastruktur intinya. Ini akan memungkinkan pengembang tema dan plugin membuat API khusus untuk disertakan dalam tema dan plugin mereka. Tapi karena, endpoint tidak akan disertakan pada tahap ini, ini akan membatasi kegunaan API pada awalnya.

Kesenjangan antara kedua rilis tersebut akan memberi tim inti WP committer cukup waktu untuk meninjau endpoint API.

Keuntungan lain yang akan dibawa WP REST API ke komunitas WordPress adalah penggunaan GitHub dalam versi yang mengendalikan proyek. Karena semua kontribusi ke WordPress dibuat melalui SVN dan Trac, tim WP RES API cukup percaya diri untuk memperbaiki proses kontribusi dengan menjembatani kesenjangan antara Trac dan GitHub.

Setelah menggabungkan API menjadi inti, kita dapat berharap dapat melihat perkembangan pesat di area lain termasuk otentikasi OAuth 1.0a.

Alat Alat yang Diperlukan

Untuk memulai pengujian dengan API REST WP, kita memerlukan klien HTTP yang akan digunakan untuk mengirim permintaan ke server dan melihat jawabannya. Ini benar-benar masalah pilihan Anda tapi saya akan menggunakan Postman untuk Google Chrome selama seri ini. Alternatif lain untuk Postman adalah:

Postman memungkinkan kita untuk membuat permintaan HTTP cepat dengan berbagai metode, melihat respon dari server dan menguji konfigurasi untuk otentikasi. Semua fitur ini akan sangat berguna saat bekerja dengan WP REST API.

Hal berikutnya yang perlu kita miliki di server kita adalah WP-CLI. Dengan WP-CLI, kita bisa mengatur instalasi WordPress dari dalam konsol tanpa perlu membuka jendela browser. Kita perlu menggunakan WP-CLI di bagian selanjutnya dari rangkaian ini saat menyiapkan otentikasi OAuth 1.0a. Anda dapat menemukan petunjuk instalasi di situs resminya.

Selain klien HTTP dan WP-CLI, kita juga membutuhkan data demo untuk instalasi WordPress kita. Saya sarankan untuk memeriksa Theme Unit Test (XML) atau plugin Demo Data Creator yang memungkinkan pembuatan beberapa posting, halaman, dan pengguna.

Memasang Plugin

Pada saat penulisan tutorial ini, versi stabil saat ini adalah 1.2.2 yang bisa ditemukan di repositori resmi. Dalam seri ini, kita akan bekerja dengan versi 2.0 karena telah ditulis ulang dari bawah ke atas dan berisi banyak perubahan. Anda bisa ambil versi 2 beta dari halaman plugin resminya atau dari repositori GitHub-nya.

Harap dicatat bahwa sangat tidak disarankan untuk menginstal beta saat ini di lingkungan produksi Anda. Saya telah menyiapkan lingkungan WordPress lokal dan saya sarankan Anda melakukannya untuk tujuan pengembangan dan pengujian.

Untuk menginstal plugin dari gudang GitHub, buka terminal Anda dan tarik plugin setelah masuk ke direktori /wp-content/plugins/ Anda:

Plugin akan didownload di direktori /WP-API/.

Anda bisa mengaktifkannya dari admin WordPress Anda untuk terus melakukan pengujian dengannya.

Agar plugin WP REST API bekerja, Anda perlu mengaktifkan pretty permalink dengan WordPress. Diasumsikan di sini bahwa Anda sudah tahu untuk melakukan tindakan dasar ini. Jika tidak, jangan khawatir seperti WordPress.org telah membuat sesuatu untuk Anda.

Menilai Ketersediaan API

Setelah plugin terinstal, kita bisa menilai ketersediaan API di server kita. Kami tidak terbatas hanya menggunakan API di situs kami, sebenarnya Anda menggunakannya di situs mana pun yang telah menginstal dan mengaktifkannya. Untuk memeriksa API di situs lain, kami dapat mengirim permintaan HEAD ke situs sebagai berikut menggunakan klien HTTP Anda:

Ini akan mengembalikan sesuatu seperti berikut di header tanggapan:

Response HeaderResponse HeaderResponse Header

Link header menunjuk ke rute root API WP yang dalam kasus kami adalah sebagai berikut:

API juga dapat ditemukan melalui peramban JavaScript (atau jQuery) dengan menanyakan DOM untuk elemen <link> yang sesuai seperti berikut:

Dari sini kita bisa mulai mengambil kembali konten dari situs melalui WP REST API. Harap dicatat bahwa hanya permintaan yang diautentikasi yang dapat mengedit atau memperbarui konten di situs dan saya menyimpan subjek pembuatan autentikasi untuk dua bagian berikutnya dari seri ini.

Ada Apa Selanjutnya

Di bagian pendahuluan dari seri ini, kita belajar cukup banyak tentang arsitektur REST, WP REST API dan HTTP itu sendiri. Kita pertama kali melihat konsep dasar seperti arsitektur REST dan bagaimana hal itu dapat membantu pengembang membuat aplikasi yang lebih baik. Kemudian kita belajar tentang HTTP, verbnya, dan tipe responnya. Kita juga melihat sejarah singkat tentang API di WordPress dan bagaimana WP REST API berbeda dari pendahulunya.

Di bagian akhir tutorial ini, kita memasang plugin dari GitHub. Setelah itu kita membiasakan diri dengan permintaan HEAD yang dapat digunakan untuk menentukan ketersediaan API di server kita dan juga di server lain.

Setelah menyiapkan lingkungan kerja dasar, kita siap untuk bekerja dengan fitur yang disediakan WP REST API. Bagian berikutnya dari seri ini, kita akan melihat cara untuk menyiapkan metode otentikasi yang didukung oleh API. Metode otentikasi ini akan diperlukan saat mengirim permintaan untuk mengambil, membuat, memperbarui atau menghapus konten. Jadi nantikanlah.


Advertisement
Did you find this post useful?
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.