Dapat dimengerti untuk sedikit bingung tentang cara menggunakan REST dengan benar berdasarkan semua cara yang saya lihat perusahaan besar merancang API REST mereka.
Anda benar karena REST adalah sistem Pengumpulan Sumber Daya. Itu singkatan dari Representational State Transfer. Bukan definisi yang bagus jika Anda bertanya kepada saya. Tetapi konsep utamanya adalah 4 HTTP VERBs dan tidak bernegara.
Bagian penting yang perlu diperhatikan adalah bahwa Anda hanya memiliki 4 KATA KERJA dengan REST. Ini adalah GET, POST, PUT dan DELETE. resendContoh Anda akan menambahkan kata kerja baru ke REST. Ini harus menjadi bendera merah.
pertanyaan 1
Penting untuk menyadari bahwa penelepon REST API Anda tidak perlu tahu bahwa melakukan PUTkoleksi Anda akan menghasilkan email yang dihasilkan. Baunya bocor bagiku. Apa yang bisa mereka ketahui adalah bahwa melakukan PUTdapat menghasilkan tugas tambahan yang bisa mereka tanyakan nanti. Mereka akan mengetahui hal ini dengan melakukan GETpada sumber daya yang baru dibuat. Itu GETakan mengembalikan sumber daya dan semua Taskid sumber daya yang terkait dengannya. Anda kemudian dapat meminta tugas-tugas itu untuk menentukan status mereka dan bahkan mengirimkan yang baru Task.
Anda punya beberapa pilihan.
REST - Pendekatan berbasis sumber daya tugas
Buat taskssumber daya di mana Anda bisa mengirimkan tugas spesifik ke sistem Anda untuk melakukan tindakan. Anda kemudian dapat GETtugas berdasarkan IDitu dikembalikan untuk menentukan statusnya.
Atau Anda dapat mencampur dalam SOAP over HTTPLayanan Web untuk menambahkan beberapa RPC ke arsitektur Anda.
meminta semua tugas untuk sumber daya tertentu
GET http://server/api/myCollection/123/tasks
{ "tasks" :
[ { "22333" : "http://server/api/tasks/223333" } ]
}
contoh sumber daya tugas
PUT http://server/api/tasks
{
"type" : "send-email" ,
"parameters" :
{
"collection-type" : "foo" ,
"collection-id" : "123"
}
}
==> mengembalikan id tugas
223334
GET http://server/api/tasks/223334
{
"status" : "complete" ,
"date" : "whenever"
}
REST- Menggunakan POST untuk memicu tindakan
Anda selalu dapat POSTmenambahkan data ke sumber daya. Menurut pendapat saya ini akan melanggar semangat REST tetapi masih sesuai.
Anda dapat melakukan POST yang mirip dengan ini:
POST http://server/api/collection/123
{ "action" : "send-email" }
Anda akan memperbarui sumber daya 123 dari pengumpulan dengan data tambahan. Data tambahan itu pada dasarnya adalah tindakan yang memberi tahu backend untuk mengirim email untuk sumber itu.
Masalah yang saya miliki dengan ini adalah bahwa GETpada sumber daya akan mengembalikan data yang diperbarui ini. Namun, ini akan menyelesaikan kebutuhan Anda dan masih TETAP.
SOAP - Layanan Web yang menerima sumber daya yang diperoleh dari REST
Buat WebService baru di mana Anda dapat mengirim email berdasarkan ID sumber daya sebelumnya dari REST API. Saya tidak akan membahas detail tentang SOAP di sini karena pertanyaan awalnya adalah tentang REST dan dua konsep / teknologi ini tidak boleh dibandingkan karena ini adalah Apel dan Jeruk .
Pertanyaan 2
Anda juga memiliki beberapa opsi di sini:
Tampaknya banyak perusahaan besar yang menerbitkan REST API memaparkan searchkoleksi yang benar-benar hanya cara untuk mengirimkan parameter kueri untuk mengembalikan sumber daya.
GET http://server/api/search?q="type = myCollection & someField >= someval"
Yang akan mengembalikan koleksi sumber daya REST yang sepenuhnya memenuhi syarat seperti:
{
"results" :
{ [
"location" : "http://server/api/myCollection/1",
"location" : "http://server/api/myCollection/9",
"location" : "http://server/api/myCollection/56"
]
}
}
Atau Anda dapat mengizinkan sesuatu seperti MVEL sebagai parameter kueri.
Pertanyaan 3
Saya lebih suka sub-level daripada harus kembali dan meminta sumber daya lain dengan parameter kueri. Saya tidak percaya ada aturan apa pun. Anda dapat menerapkan kedua cara dan memungkinkan pemanggil untuk memutuskan mana yang lebih tepat berdasarkan pada bagaimana mereka pertama kali masuk ke dalam sistem.
Catatan
Saya tidak setuju tentang komentar keterbacaan dari orang lain. Meskipun demikian beberapa orang mungkin berpikir REST masih belum untuk konsumsi manusia. Ini untuk konsumsi mesin. Jika saya ingin melihat Tweet saya, saya menggunakan situs web reguler Twitters. Saya tidak melakukan REST GET dengan API mereka. Jika saya ingin melakukan sesuatu secara pemrograman dengan tweet saya maka saya menggunakan REST API mereka. Ya API harus dimengerti, tetapi Anda gteyang tidak buruk, itu hanya tidak intuitif.
Hal utama lainnya dengan REST adalah bahwa Anda harus dapat memulai kapan saja di API Anda dan menavigasi ke semua sumber daya terkait TANPA tahu URL persis dari sumber daya lain sebelumnya. Hasil GETKATA KERJA di REST harus mengembalikan URL REST lengkap dari sumber daya yang dirujuk. Jadi, alih-alih kueri yang mengembalikan ID Personobjek, itu akan mengembalikan URL yang Memenuhi Kualifikasi seperti http://server/api/people/13. Kemudian Anda selalu dapat menavigasi hasil secara terprogram meskipun URL berubah.
Respon terhadap komentar
Di dunia nyata sebenarnya ada hal-hal yang perlu terjadi yang tidak membuat, membaca, memperbarui atau menghapus (CRUD) sumber daya.
Tindakan tambahan dapat diambil pada sumber daya. Basis data relasional yang tipikal mendukung konsep Prosedur yang Disimpan. Ini adalah perintah tambahan yang dapat dieksekusi pada set data. REST pada dasarnya tidak memiliki konsep itu. Dan tidak ada alasan untuk itu. Jenis tindakan ini sempurna untuk Layanan Web RPC atau SOAP.
Ini adalah masalah umum yang saya lihat dengan REST API. Pengembang tidak menyukai batasan konseptual yang mengelilingi REST sehingga mereka mengadaptasinya untuk melakukan apa pun yang mereka inginkan. Itu mematahkannya dari menjadi layanan tenang. Pada dasarnya URL itu menjadi GETpanggilan pada servlets pseudo-REST.
Anda punya beberapa pilihan:
- Buat sumber daya tugas
- Mendukung
POSTmemasukkan data tambahan ke sumber daya untuk melakukan suatu tindakan.
- Tambahkan perintah tambahan melalui SOAP Web Service.
Jika Anda menggunakan parameter kueri, HTTP VERB mana yang akan Anda gunakan untuk mengirim ulang email?
GET- Apakah ini mengirim ulang email DAN mengembalikan data sumber daya? Bagaimana jika suatu sistem menyimpan URL itu dan memperlakukannya seperti URL unik untuk sumber daya itu. Setiap kali mereka menekan URL itu akan mengirim ulang email.POST - Anda sebenarnya tidak mengirim data baru ke sumber daya, hanya parameter kueri tambahan.
Berdasarkan semua persyaratan yang diberikan, melakukan POSTpada sumber daya dengan action fielddata POST akan menyelesaikan masalah.