Pertanyaan Apa sebenarnya pemrograman RESTful?


Apa sebenarnya pemrograman RESTful?


3628
2018-03-22 14:45


asal


Jawaban:


Sebuah gaya arsitektur bernama REST (Representational State Transfer) menganjurkan bahwa aplikasi web harus menggunakan HTTP seperti itu awalnya dibayangkan. Pencarian harus digunakan GET permintaan. PUT, POST, dan DELETE permintaan harus digunakan untuk mutasi, kreasi, dan penghapusan masing-masing.

Pendukung REST cenderung menyukai URL, seperti

http://myserver.com/catalog/item/1729

tetapi arsitektur REST tidak memerlukan "URL cantik" ini. A MENDAPATKAN permintaan dengan parameter

http://myserver.com/catalog?item=1729

setiap bit RESTful.

Harap diingat bahwa permintaan GET tidak boleh digunakan untuk memperbarui informasi. Misalnya, permintaan GET untuk menambahkan item ke keranjang

http://myserver.com/addToCart?cart=314159&item=1729

tidak akan sesuai. MENDAPATKAN permintaan idempoten. Artinya, mengeluarkan permintaan dua kali seharusnya tidak berbeda dari mengeluarkannya satu kali. Itulah yang membuat permintaan tersebut dapat disimpan dalam cache. Permintaan "tambahkan ke keranjang" tidak idempoten — menerbitkannya dua kali menambahkan dua salinan item ke keranjang. Permintaan POST jelas sesuai dalam konteks ini. Jadi, bahkan a Aplikasi web RESTful membutuhkan pangsa permintaan POST.

Ini diambil dari buku yang sangat bagus Wajah JavaServer inti buku karya David M. Geary.


540
2018-04-15 11:26



BERISTIRAHAT adalah prinsip arsitektur yang mendasari web. Hal yang luar biasa tentang web adalah kenyataan bahwa klien (browser) dan server dapat berinteraksi dengan cara yang rumit tanpa klien mengetahui apa-apa sebelumnya tentang server dan sumber daya yang dihostingnya. Kendala kuncinya adalah bahwa server dan klien harus sama-sama menyetujui media digunakan, yang dalam kasus web adalah HTML.

API yang mematuhi prinsip-prinsip BERISTIRAHAT tidak mengharuskan klien untuk mengetahui apa pun tentang struktur API. Sebaliknya, server perlu memberikan informasi apa pun yang diperlukan klien untuk berinteraksi dengan layanan. Sebuah Formulir HTML adalah contoh dari ini: Server menentukan lokasi sumber daya dan bidang yang diperlukan. Browser tidak tahu sebelumnya di mana untuk mengirimkan informasi, dan tidak tahu sebelumnya informasi apa yang harus dikirimkan. Kedua bentuk informasi sepenuhnya disediakan oleh server. (Prinsip ini disebut HATEOAS: Hypermedia Sebagai Mesin Negara Aplikasi.)

Jadi, bagaimana ini berlaku untuk HTTP, dan bagaimana itu bisa diimplementasikan dalam praktek? HTTP berorientasi pada verba dan sumber daya. Dua kata kerja dalam penggunaan utama adalah GET dan POST, yang saya rasa semua orang akan mengenali. Namun, standar HTTP mendefinisikan beberapa yang lain seperti PUT dan DELETE. Kata kerja ini kemudian diterapkan ke sumber daya, sesuai dengan instruksi yang diberikan oleh server.

Sebagai contoh, Mari kita bayangkan bahwa kita memiliki database pengguna yang dikelola oleh layanan web. Layanan kami menggunakan hypermedia khusus berdasarkan JSON, yang kami tetapkan mimetype aplikasi / json + userdb (Mungkin juga ada aplikasi / xml + userdb dan aplikasi / apa pun + userdb - banyak jenis media yang mungkin didukung). Klien dan server telah diprogram untuk memahami format ini, tetapi mereka tidak tahu apa-apa tentang satu sama lain. Sebagai Roy Fielding menunjukkan:

API REST harus menghabiskan hampir semua upaya deskriptifnya di   mendefinisikan jenis media (s) yang digunakan untuk mewakili sumber daya dan mengemudi   status aplikasi, atau dalam menentukan nama relasi diperpanjang dan / atau   hypert-enabled mark-up untuk jenis media standar yang ada.

Permintaan untuk sumber daya dasar / mungkin mengembalikan sesuatu seperti ini:

Permintaan

GET /
Accept: application/json+userdb

Tanggapan

200 OK
Content-Type: application/json+userdb

{
    "version": "1.0",
    "links": [
        {
            "href": "/user",
            "rel": "list",
            "method": "GET"
        },
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

Kami tahu dari deskripsi media kami bahwa kami dapat menemukan informasi tentang sumber daya terkait dari bagian yang disebut "tautan". Ini disebut Kontrol hypermedia. Dalam hal ini, kita dapat mengetahui dari bagian tersebut bahwa kita dapat menemukan daftar pengguna dengan membuat permintaan lain /user:

Permintaan

GET /user
Accept: application/json+userdb

Tanggapan

200 OK
Content-Type: application/json+userdb

{
    "users": [
        {
            "id": 1,
            "name": "Emil",
            "country: "Sweden",
            "links": [
                {
                    "href": "/user/1",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/1",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/1",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        },
        {
            "id": 2,
            "name": "Adam",
            "country: "Scotland",
            "links": [
                {
                    "href": "/user/2",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/2",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/2",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        }
    ],
    "links": [
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

Kami dapat memberi tahu banyak dari tanggapan ini. Misalnya, kita sekarang tahu kita bisa membuat pengguna baru dengan POSTING ke /user:

Permintaan

POST /user
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Karl",
    "country": "Austria"
}

Tanggapan

201 Created
Content-Type: application/json+userdb

{
    "user": {
        "id": 3,
        "name": "Karl",
        "country": "Austria",
        "links": [
            {
                "href": "/user/3",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/3",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/3",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

Kami juga tahu bahwa kami dapat mengubah data yang ada:

Permintaan

PUT /user/1
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Emil",
    "country": "Bhutan"
}

Tanggapan

200 OK
Content-Type: application/json+userdb

{
    "user": {
        "id": 1,
        "name": "Emil",
        "country": "Bhutan",
        "links": [
            {
                "href": "/user/1",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/1",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/1",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

Perhatikan bahwa kami menggunakan kata kerja HTTP yang berbeda (GET, PUT, POST, DELETE, dll.) Untuk memanipulasi sumber daya ini, dan bahwa satu-satunya pengetahuan yang kami anggap pada bagian klien adalah definisi media kami.

Bacaan lebih lanjut:

(Jawaban ini telah menjadi subyek kritik dalam jumlah yang cukup untuk kehilangan intinya. Untuk sebagian besar, itu telah menjadi kritik yang adil. Apa yang awalnya saya jelaskan lebih sesuai dengan bagaimana REST biasanya diterapkan beberapa tahun yang lalu ketika saya pertama kali menulis ini, daripada arti yang sebenarnya. Saya telah merevisi jawaban untuk lebih mewakili makna sebenarnya.)


2788
2018-03-22 19:37



Pemrograman RESTful adalah tentang:

  • sumber daya diidentifikasi oleh pengenal tetap: URI adalah pilihan pengidentifikasi yang ada di mana-mana hari ini
  • sumber daya dimanipulasi menggunakan seperangkat kata kerja umum: metode HTTP adalah kasus yang biasa terlihat - yang terhormat Create, Retrieve, Update, Delete menjadi POST, GET, PUT, dan DELETE. Tetapi REST tidak terbatas pada HTTP, ini hanya merupakan transportasi yang paling umum digunakan saat ini.
  • representasi sebenarnya yang diambil untuk sumber daya bergantung pada permintaan dan bukan pengenal: gunakan header Terima untuk mengontrol apakah Anda ingin XML, HTTP, atau bahkan Objek Java yang mewakili sumber daya
  • mempertahankan negara dalam objek dan mewakili negara dalam representasi
  • mewakili hubungan antara sumber daya dalam representasi sumber daya: tautan antara objek tertanam langsung dalam representasi
  • representasi sumber daya menggambarkan bagaimana representasi dapat digunakan dan dalam keadaan apa ia harus dibuang / diambil dengan cara yang konsisten: penggunaan header HTTP Cache-Control

Yang terakhir mungkin yang paling penting dalam hal konsekuensi dan efektivitas REST secara keseluruhan. Secara keseluruhan, sebagian besar diskusi RESTful tampaknya berpusat pada HTTP dan penggunaannya dari browser dan apa yang tidak. Saya mengerti bahwa R. Fielding menciptakan istilah ketika dia menggambarkan arsitektur dan keputusan yang mengarah ke HTTP. Tesisnya lebih tentang arsitektur dan kemampuan cache sumber daya daripada tentang HTTP.

Jika Anda benar-benar tertarik pada arsitektur yang tenang dan mengapa itu berhasil, bacalah tesisnya beberapa kali dan baca semuanya bukan hanya Bab 5! Selanjutnya lihat mengapa DNS berfungsi. Baca tentang organisasi hierarkis DNS dan bagaimana rujukan bekerja. Kemudian baca dan pertimbangkan cara kerja cache DNS. Akhirnya, baca spesifikasi HTTP (RFC2616 dan RFC3040 khususnya) dan mempertimbangkan bagaimana dan mengapa caching bekerja seperti yang dilakukannya. Akhirnya, itu hanya akan mengklik. Wahyu terakhir bagi saya adalah ketika saya melihat kesamaan antara DNS dan HTTP. Setelah ini, pahami mengapa SOA dan Message Passing Interfaces dapat ditingkatkan mulai diklik.

Saya pikir bahwa trik yang paling penting untuk memahami pentingnya arsitektur dan implikasi kinerja dari RESTful dan Tidak Dibagikan arsitektur adalah untuk tidak terpaku pada detail teknologi dan implementasi. Berkonsentrasilah pada siapa yang memiliki sumber daya, siapa yang bertanggung jawab untuk membuat / mempertahankannya, dll. Kemudian pikirkan tentang representasi, protokol, dan teknologi.


500
2017-07-04 05:47



Seperti inilah bentuknya.

Buat pengguna dengan tiga properti:

POST /user
fname=John&lname=Doe&age=25

Server merespons:

200 OK
Location: /user/123

Di masa mendatang, Anda dapat mengambil informasi pengguna:

GET /user/123

Server merespons:

200 OK
<fname>John</fname><lname>Doe</lname><age>25</age>

Untuk memodifikasi rekaman (lname dan age akan tetap tidak berubah):

PATCH /user/123
fname=Johnny

Untuk memperbarui catatan (dan akibatnya lname dan age akan menjadi NULL):

PUT /user/123
fname=Johnny

392
2017-11-18 20:46



Sebuah buku hebat tentang REST adalah REST in Practice.

Yang harus dibaca adalah Transfer Negara Representasi (REST) dan API REST harus di-hypertext 

Lihat artikel Martin Fowlers Model Kematangan Richardson (RMM) untuk penjelasan tentang layanan RESTful.

Richardson Maturity Model

Menjadi RESTful a Service harus memenuhi Hypermedia sebagai Mesin Negara Aplikasi. (HATEOAS), yaitu, perlu mencapai level 3 di RMM, Baca artikel untuk detail atau slide dari obrolan qcon.

Kendala HATEOAS adalah akronim   untuk Hypermedia sebagai   Negara Aplikasi. Prinsip ini   pembeda utama antara REST   dan sebagian besar bentuk server klien lainnya   sistem.

...

Seorang klien dari kebutuhan aplikasi RESTful   hanya mengetahui satu URL tetap untuk diakses   saya t. Semua tindakan di masa depan seharusnya   dapat ditemukan secara dinamis dari   hypermedia links termasuk dalam   representasi dari sumber daya itu   dikembalikan dari URL itu.   Jenis media standar juga   diharapkan dapat dipahami oleh siapapun   klien yang mungkin menggunakan API RESTful.   (Dari Wikipedia, ensiklopedia gratis)

Uji REST Litmus untuk Kerangka Web adalah tes kematangan serupa untuk kerangka web.

Mendekati REST murni: Belajar mencintai HATEOAS adalah koleksi tautan yang bagus.

REST versus SOAP untuk Public Cloud membahas tingkat penggunaan REST saat ini.

REST dan versi membahas Extensibility, Versioning, Evolvability, dll.  melalui Modifiability


170
2018-03-22 15:20



Apa itu REST?

REST adalah singkatan dari Representational State Transfer. (Kadang-kadang   dieja "ReST".) Ini bergantung pada stateless, client-server, cacheable   protokol komunikasi - dan dalam hampir semua kasus, HTTP   protokol digunakan.

REST adalah gaya arsitektur untuk merancang aplikasi jaringan.   Idenya adalah bahwa, daripada menggunakan mekanisme yang kompleks seperti CORBA,   RPC atau SOAP untuk menghubungkan antar mesin, HTTP sederhana digunakan untuk membuatnya   panggilan antar mesin.

Dalam banyak hal, World Wide Web sendiri, berdasarkan HTTP, dapat dilihat   sebagai arsitektur berbasis REST. Aplikasi RESTful menggunakan permintaan HTTP   untuk memposting data (buat dan / atau perbarui), baca data (mis., buat kueri),   dan hapus data. Dengan demikian, REST menggunakan HTTP untuk keempat CRUD   (Buat / Baca / Perbarui / Hapus) operasi.

REST adalah alternatif ringan untuk mekanisme seperti RPC (Remote   Prosedur Panggilan) dan Layanan Web (SOAP, WSDL, et al.). Nanti, kami akan melakukannya   lihat berapa REST yang lebih sederhana.

Meskipun sederhana, REST adalah fitur lengkap; pada dasarnya ada   tidak ada yang dapat Anda lakukan di Layanan Web yang tidak dapat dilakukan dengan RESTful   Arsitektur. REST bukan "standar". Tidak akan pernah ada W3C   rekomendasi untuk REST, misalnya. Dan sementara ada REST   kerangka kerja pemrograman, bekerja dengan REST sangat sederhana yang Anda bisa   sering "gulung Anda sendiri" dengan fitur perpustakaan standar dalam bahasa seperti   Perl, Java, atau C #.

Salah satu referensi terbaik yang saya temukan ketika saya mencoba untuk menemukan makna nyata yang sederhana dari istirahat.

http://rest.elkstein.org/


128
2018-03-22 14:53



REST menggunakan berbagai metode HTTP (terutama GET / PUT / DELETE) untuk memanipulasi data.

Daripada menggunakan URL tertentu untuk menghapus metode (misalnya, /user/123/delete), Anda akan mengirim permintaan DELETE ke /user/[id] URL, untuk mengedit pengguna, untuk mengambil info pada pengguna yang Anda kirimi permintaan GET /user/[id]

Sebagai contoh, sebagai gantinya satu set URL yang mungkin terlihat seperti beberapa hal berikut ..

GET /delete_user.x?id=123
GET /user/delete
GET /new_user.x
GET /user/new
GET /user?id=1
GET /user/id/1

Anda menggunakan "verba" HTTP dan memiliki ..

GET /user/2
DELETE /user/2
PUT /user

85
2017-07-12 16:33



Ini pemrograman di mana arsitektur sistem Anda sesuai Gaya REST ditata oleh Roy Fielding di tesisnya. Karena ini adalah gaya arsitektur yang menggambarkan web (kurang lebih), banyak orang tertarik dengannya.

Jawaban bonus: Tidak. Kecuali Anda mempelajari arsitektur perangkat lunak sebagai akademik atau merancang layanan web, tidak ada alasan untuk mendengar istilah tersebut.


63
2018-03-23 17:11



Saya akan mengatakan pemrograman RESTful adalah tentang menciptakan sistem (API) yang mengikuti gaya arsitektur REST.

Saya menemukan tutorial yang fantastis, singkat, dan mudah dimengerti tentang REST oleh Dr. M. Elkstein dan mengutip bagian penting yang akan menjawab pertanyaan Anda untuk sebagian besar:

Pelajari REST: A Tutorial

REST adalah sebuah gaya arsitektur untuk merancang aplikasi jaringan.   Idenya adalah bahwa, daripada menggunakan mekanisme yang kompleks seperti CORBA,   RPC atau SOAP untuk menghubungkan antar mesin, HTTP sederhana digunakan untuk membuatnya   panggilan antar mesin.

  • Dalam banyak hal, World Wide Web itu sendiri, berdasarkan HTTP, dapat dilihat sebagai arsitektur berbasis REST.

Aplikasi RESTful menggunakan permintaan HTTP untuk memposting data (buat dan / atau   pembaruan), membaca data (mis., membuat kueri), dan menghapus data. Dengan demikian, REST   menggunakan HTTP untuk keempat operasi CRUD (Create / Read / Update / Delete).

Saya tidak berpikir Anda harus merasa bodoh karena tidak mendengar tentang REST di luar Stack Overflow ..., saya akan berada dalam situasi yang sama !; jawaban atas pertanyaan SO lainnya ini Mengapa REST semakin besar sekarang bisa bisa meredakan beberapa perasaan.


43
2017-07-25 09:05



Saya minta maaf jika saya tidak menjawab pertanyaan secara langsung, tetapi lebih mudah untuk memahami semua ini dengan contoh yang lebih terperinci. Fielding tidak mudah dipahami karena semua abstraksi dan terminologi.

Ada contoh yang cukup bagus di sini:

Menjelaskan REST dan Hypertext: Spam-E Robot Pembersih Spam

Dan bahkan lebih baik, ada penjelasan yang bersih dengan contoh sederhana di sini (powerpoint lebih komprehensif, tetapi Anda bisa mendapatkan sebagian besar dalam versi html):

http://www.xfront.com/REST.ppt atau http://www.xfront.com/REST.html

Setelah membaca contoh, saya bisa melihat mengapa Ken mengatakan bahwa REST adalah hypertext-driven. Saya tidak benar-benar yakin bahwa dia benar, karena / user / 123 adalah URI yang mengarah ke sumber daya, dan tidak jelas bagi saya bahwa itu tidak BENAR hanya karena klien tahu tentang "out-of-band."

Dokumen xfront itu menjelaskan perbedaan antara REST dan SOAP, dan ini sangat membantu juga. Saat Fielding berkata, "Itu adalah RPC. Itu berteriak RPC.", jelas bahwa RPC tidak RESTful, jadi sangat berguna untuk melihat alasan yang tepat untuk ini. (SOAP adalah tipe RPC.)


43
2018-03-22 16:36