Apa sebenarnya pemrograman RESTful?

Apa sebenarnya pemrograman RESTful?

Sebuah gaya arsitektur yang disebut SISA (Negara Transfer) pendukung bahwa aplikasi web harus menggunakan HTTP seperti yang awalnya direncanakan . Pencarian harus menggunakan GETpermintaan. PUT,, POSTdan DELETEpermintaan harus digunakan untuk masing-masing mutasi, pembuatan, dan penghapusan .

Pendukung REST cenderung mendukung URL, seperti

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

tetapi arsitektur REST tidak memerlukan "URL cantik" ini. Permintaan GET dengan parameter

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

setiap bit tenang.

Ingatlah bahwa permintaan GET tidak boleh digunakan untuk memperbarui informasi. Misalnya, permintaan GET untuk menambahkan item ke troli

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

tidak akan sesuai. Permintaan GET harus idempoten . Artinya, mengeluarkan permintaan dua kali seharusnya tidak berbeda dengan menerbitkannya sekali. Itulah yang membuat permintaan bisa disimpan. Permintaan "tambahkan ke troli" bukan idempoten — menerbitkannya dua kali menambahkan dua salinan item ke troli. Permintaan POST jelas sesuai dalam konteks ini. Dengan demikian, bahkan aplikasi web yang tenang membutuhkan bagian dari permintaan POST.

Ini diambil dari buku Core JavaServer Faces yang ditulis oleh David M. Geary.

REST adalah prinsip arsitektur web yang mendasarinya. Hal yang luar biasa tentang web adalah kenyataan bahwa klien (browser) dan server dapat berinteraksi dengan cara yang rumit tanpa klien mengetahui apa pun sebelumnya tentang server dan sumber daya yang dihostingnya. Kendala utama adalah bahwa server dan klien harus menyetujui media yang digunakan, yang dalam hal web adalah HTML .

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

Jadi, bagaimana ini berlaku untuk HTTP , dan bagaimana itu bisa diimplementasikan dalam praktik? HTTP berorientasi pada kata kerja dan sumber daya. Dua kata kerja dalam penggunaan arus utama adalah GETdan POST, yang saya pikir semua orang akan kenal. Namun, standar HTTP mendefinisikan beberapa yang lain seperti PUTdan DELETE. Kata kerja ini kemudian diterapkan pada sumber daya, sesuai dengan instruksi yang diberikan oleh server.

Misalnya, Mari kita bayangkan bahwa kita memiliki basis data pengguna yang dikelola oleh layanan web. Layanan kami menggunakan hypermedia khusus berdasarkan JSON, untuk itu kami menetapkan mimetype application/json+userdb(Mungkin juga ada application/xml+userdbdan application/whatever+userdb- banyak jenis media mungkin didukung). Klien dan server keduanya telah diprogram untuk memahami format ini, tetapi mereka tidak tahu apa-apa tentang satu sama lain. Seperti yang ditunjukkan oleh Roy Fielding :

REST API harus menghabiskan hampir semua upaya deskriptifnya dalam menentukan jenis media yang digunakan untuk mewakili sumber daya dan status aplikasi mengemudi, atau dalam mendefinisikan nama hubungan yang diperluas dan / atau mark-up yang memungkinkan hypertext 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 uraian media kami bahwa kami dapat menemukan informasi tentang sumber daya terkait dari bagian yang disebut "tautan". Ini disebut kontrol Hypermedia . Dalam hal ini, kami dapat memberi tahu dari bagian seperti itu bahwa kami dapat menemukan daftar pengguna dengan mengajukan permintaan lain untuk /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 bisa tahu banyak dari respons ini. Misalnya, kita sekarang tahu bahwa kita dapat membuat pengguna baru dengan POSTcara /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 kita menggunakan kata kerja HTTP yang berbeda ( GET, PUT, POST, DELETEdll) untuk memanipulasi sumber daya ini, dan bahwa satu-satunya pengetahuan kita anggap pada bagian klien adalah definisi media kita.

Bacaan lebih lanjut:

• Banyak jawaban yang jauh lebih baik di halaman ini.
• Bagaimana saya menjelaskan REST kepada istri saya .
• Bagaimana saya menjelaskan REST kepada istri saya .
• Pikiran Martin Fowler
• API PayPal memiliki kontrol hypermedia

(Jawaban ini telah menjadi subyek cukup banyak kritik karena melewatkan poin. Sebagian besar, itu adalah kritik yang adil. Apa yang saya jelaskan sebelumnya lebih sesuai dengan bagaimana REST biasanya diterapkan beberapa tahun yang lalu ketika saya pertama menulis ini, daripada arti sebenarnya. Saya telah merevisi jawaban untuk lebih mewakili makna sebenarnya.)

Pemrograman yang tenang adalah tentang:

• sumber daya diidentifikasi oleh pengidentifikasi persisten: URI adalah pilihan pengidentifikasi di mana-mana saat ini
• sumber dimanipulasi menggunakan seperangkat kata kerja: HTTP metode adalah kasus biasa terlihat - YM Create, Retrieve, Update, Deletemenjadi POST, GET, PUT, dan DELETE. Tetapi REST tidak terbatas pada HTTP, itu hanya transportasi yang paling umum digunakan saat ini.
• representasi aktual yang diambil untuk suatu sumber daya bergantung pada permintaan dan bukan pengidentifikasi: gunakan Terima header untuk mengontrol apakah Anda ingin XML, HTTP, atau bahkan Obyek 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 itu harus dibuang / diambil kembali secara konsisten: penggunaan header HTTP Cache-Control

Yang terakhir mungkin yang paling penting dalam hal konsekuensi dan keefektifan REST secara keseluruhan. Secara keseluruhan, sebagian besar diskusi tenang 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 sumber daya cache daripada tentang HTTP.

Jika Anda benar-benar tertarik dengan apa itu arsitektur RESTful dan mengapa itu bekerja, bacalah tesisnya beberapa kali dan bacalah semuanya bukan hanya Bab 5! Selanjutnya lihat mengapa DNS bekerja . Baca tentang organisasi hierarki DNS dan cara kerja rujukan. Kemudian baca dan pertimbangkan cara kerja caching DNS. Akhirnya, baca spesifikasi HTTP (khususnya RFC2616 dan RFC3040 ) dan pertimbangkan bagaimana dan mengapa caching berfungsi sebagaimana mestinya . Akhirnya, itu hanya akan klik. Wahyu terakhir bagi saya adalah ketika saya melihat kesamaan antara DNS dan HTTP. Setelah ini, memahami mengapa SOA dan Interface Passing Interface dapat diskalakan mulai mengklik.

Saya berpikir bahwa trik paling penting untuk memahami kepentingan arsitektur dan implikasi kinerja arsitektur RESTful dan Shared Nothing adalah untuk menghindari terjebak pada rincian teknologi dan implementasi. Berkonsentrasilah pada siapa yang memiliki sumber daya, siapa yang bertanggung jawab untuk menciptakan / memeliharanya, dll. Kemudian pikirkan tentang representasi, protokol, dan teknologi.

Ini mungkin terlihat seperti.

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 catatan ( lnamedan ageakan tetap tidak berubah):

PATCH /user/123
fname=Johnny

Untuk memperbarui catatan (dan akibatnya lnamedan ageakan menjadi NULL):

PUT /user/123
fname=Johnny

Buku hebat tentang REST adalah REST in Practice .

Harus dibaca adalah Representational State Transfer (REST) dan REST APIs harus digerakkan oleh hypertext

Lihat artikel Martin Fowlers the Richardson Maturity Model (RMM) untuk penjelasan tentang apa itu layanan RESTful.

Agar tenang, sebuah layanan perlu memenuhi Hypermedia sebagai Engine of Application State. (HATEOAS) , yaitu, perlu mencapai level 3 di RMM, baca artikel untuk detail atau slide dari pembicaraan qcon .

Kendala HATEOAS adalah akronim untuk Hypermedia sebagai Engine of Application State. Prinsip ini adalah pembeda utama antara REST dan sebagian besar bentuk lain dari sistem server klien.

...

Klien aplikasi RESTful hanya perlu tahu satu URL tetap untuk mengaksesnya. Semua tindakan di masa mendatang harus dapat ditemukan secara dinamis dari tautan hypermedia yang termasuk dalam representasi sumber daya yang dikembalikan dari URL itu. Jenis media terstandarisasi juga diharapkan dipahami oleh klien mana pun yang mungkin menggunakan RESTful API. (Dari Wikipedia, ensiklopedia gratis)

REST Litmus Test untuk Kerangka Web adalah tes kematangan yang serupa untuk kerangka kerja web.

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

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

REST dan versi membahas Ekstensibilitas, Versi, Evolvabilitas, dll melalui Modifikasi

Apa itu REST?

REST adalah singkatan dari Representational State Transfer. (Kadang-kadang dieja "REST".) Itu bergantung pada protokol komunikasi yang stateless, client-server, cacheable - dan dalam hampir semua kasus, protokol HTTP 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 melakukan panggilan antar mesin.

Dalam banyak hal, World Wide Web itu sendiri, berdasarkan HTTP, dapat dilihat sebagai arsitektur berbasis REST. Aplikasi tenang menggunakan permintaan HTTP untuk mengirim data (membuat dan / atau memperbarui), membaca data (misalnya, membuat kueri), dan menghapus data. Dengan demikian, REST menggunakan HTTP untuk keempat operasi CRUD (Buat / Baca / Perbarui / Hapus).

REST adalah alternatif ringan untuk mekanisme seperti RPC (Remote Procedure Calls) dan Layanan Web (SOAP, WSDL, et al.). Nanti, kita akan melihat betapa REST lebih sederhana.

Meskipun sederhana, REST adalah fitur lengkap; pada dasarnya tidak ada yang dapat Anda lakukan di Layanan Web yang tidak dapat dilakukan dengan arsitektur yang tenang. REST bukan "standar". Misalnya, tidak akan pernah ada rekomendasi W3C untuk REST. Dan meskipun ada kerangka kerja pemrograman REST, bekerja dengan REST sangat sederhana sehingga Anda sering dapat "memutar sendiri" dengan fitur pustaka standar dalam bahasa seperti Perl, Java, atau C #.

Salah satu referensi terbaik yang saya temukan ketika saya mencoba menemukan arti sebenarnya dari istirahat.

http://rest.elkstein.org/

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

Daripada menggunakan URL spesifik untuk menghapus metode (katakanlah, /user/123/delete), Anda akan mengirim permintaan DELETE ke /user/[id]URL, untuk mengedit pengguna, untuk mengambil info tentang pengguna yang Anda kirim permintaan GET ke/user/[id]

Misalnya, alih-alih satu set URL yang mungkin terlihat seperti beberapa dari berikut ini ..

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 "kata kerja" HTTP dan memiliki ..

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

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

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

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 ini oleh Dr. M. Elkstein dan mengutip bagian penting yang akan menjawab pertanyaan Anda untuk sebagian besar:

Belajar REST: Tutorial

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 melakukan panggilan antar mesin.

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

Aplikasi tenang menggunakan permintaan HTTP untuk mengirim data (membuat dan / atau memperbarui), membaca data (misalnya, membuat kueri), dan menghapus data. Dengan demikian, REST menggunakan HTTP untuk keempat operasi CRUD (Buat / Baca / Perbarui / Hapus).

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

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

Ada contoh yang cukup bagus di sini:

Menjelaskan REST dan Hypertext: Spam-E the Robot Cleaning Spam

Dan lebih baik lagi, ada penjelasan bersih dengan contoh-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-contoh, saya bisa melihat mengapa Ken mengatakan bahwa REST didorong oleh hiperteks. Saya tidak benar-benar yakin bahwa dia benar, karena / user / 123 adalah URI yang menunjuk ke sumber daya, dan tidak jelas bagi saya bahwa itu tidak dapat diperbaiki hanya karena klien tahu tentang hal itu "out-of-band."

Dokumen xfront itu menjelaskan perbedaan antara REST dan SOAP, dan ini juga sangat membantu. Ketika Fielding berkata, " Itu adalah RPC. Ia menjerit RPC. ", Jelas bahwa RPC tidak tenang, jadi berguna untuk melihat alasan yang tepat untuk ini. (SABUN adalah jenis RPC.)

Apa itu REST?

REST dengan kata-kata resmi, REST adalah gaya arsitektur yang dibangun di atas prinsip-prinsip tertentu menggunakan fundamental "Web" saat ini. Ada 5 dasar dasar web yang dimanfaatkan untuk membuat layanan REST.

• Prinsip 1: Semuanya Sumber Daya Dalam gaya arsitektur REST, data dan fungsionalitas dianggap sumber daya dan diakses menggunakan Uniform Resource Identifiers (URIs), biasanya tautan di Web.
• Prinsip 2: Setiap Sumberdaya Diidentifikasi oleh Pengidentifikasi Unik (URI)
• Prinsip 3: Gunakan Antarmuka yang Sederhana dan Seragam
• Prinsip 4: Komunikasi Selesai oleh Representasi
• Prinsip 5: Jadilah Tanpa Kewarganegaraan

Saya melihat banyak jawaban yang mengatakan meletakkan segala sesuatu tentang pengguna 123 di sumber daya "/ user / 123" adalah TENANG.

Roy Fielding, yang menciptakan istilah itu, mengatakan REST API harus didorong oleh hiperteks . Secara khusus, "A REST API tidak boleh mendefinisikan nama sumber daya atau hierarki".

Jadi, jika jalur "/ user / 123" Anda di-hardcode pada klien, itu tidak benar-benar tenang. Penggunaan HTTP yang bagus, mungkin, mungkin juga tidak. Tapi tidak tenang. Itu harus berasal dari hiperteks.

Jawabannya sangat sederhana, ada disertasi yang ditulis oleh Roy Fielding.] 1 Dalam disertasi itu ia mendefinisikan prinsip-prinsip REST. Jika aplikasi memenuhi semua prinsip-prinsip itu, maka itu adalah aplikasi REST.

Istilah RESTful dibuat karena ppl menggunakan kata REST dengan memanggil aplikasi non-REST mereka sebagai REST. Setelah itu istilah RESTful juga habis. Saat ini kita berbicara tentang API Web dan API Hypermedia , karena sebagian besar yang disebut aplikasi REST tidak memenuhi bagian HATEOAS dari batasan antarmuka seragam.

Kendala REST adalah sebagai berikut:

1. arsitektur client-server

   Jadi tidak berfungsi misalnya dengan soket PUB / SUB, ini didasarkan pada REQ / REP.

2. komunikasi tanpa kewarganegaraan

   Jadi server tidak mempertahankan status klien. Ini berarti bahwa Anda tidak dapat menggunakan server penyimpanan sesi samping dan Anda harus mengotentikasi setiap permintaan. Klien Anda mungkin mengirim tajuk autentikasi dasar melalui koneksi terenkripsi. (Dengan aplikasi besar sulit untuk mempertahankan banyak sesi.)

3. penggunaan cache jika Anda bisa

   Jadi, Anda tidak harus melayani permintaan yang sama berulang kali.

4. antarmuka seragam sebagai kontrak umum antara klien dan server

   Kontrak antara klien dan server tidak dikelola oleh server. Dengan kata lain, klien harus dipisahkan dari implementasi layanan. Anda dapat mencapai keadaan ini dengan menggunakan solusi standar, seperti standar IRI (URI) untuk mengidentifikasi sumber daya, standar HTTP untuk bertukar pesan, tipe MIME standar untuk menggambarkan format serialisasi tubuh, metadata (mungkin kru RDF, mikroformats, dll.) Untuk menggambarkan semantik dari berbagai bagian badan pesan. Untuk memisahkan struktur IRI dari klien, Anda harus mengirim hyperlink ke klien dalam format hypermedia seperti (HTML, JSON-LD, HAL, dll.). Jadi klien dapat menggunakan metadata (kemungkinan hubungan tautan, vocab RDF) yang ditugaskan ke hyperlink untuk menavigasi mesin negara aplikasi melalui transisi keadaan yang tepat untuk mencapai tujuan saat ini.

   Misalnya ketika klien ingin mengirim pesanan ke toko web, maka klien harus memeriksa hyperlink dalam respons yang dikirim oleh toko web. Dengan memeriksa tautan yang ditemukannya dijelaskan dengan http://schema.org/OrderAction . Klien tahu vocab schema.org, sehingga mengerti bahwa dengan mengaktifkan hyperlink ini akan mengirim pesanan. Jadi itu mengaktifkan hyperlink dan mengirim POST https://example.com/api/v1/orderpesan dengan tubuh yang tepat. Setelah itu layanan memproses pesan dan merespons dengan hasil yang memiliki tajuk status HTTP yang tepat, misalnya 201 - createddengan sukses. Untuk membubuhi keterangan pesan dengan metadata terperinci, solusi standar untuk menggunakan format RDF, misalnya JSON-LD dengan vocab REST, misalnya Hydra dan domain khusus sepertischema.org atau lainnyadata vocab yang ditautkan dan mungkin vocab khusus aplikasi khusus jika diperlukan. Sekarang ini tidak mudah, itu sebabnya kebanyakan ppl menggunakan HAL dan format sederhana lainnya yang biasanya hanya menyediakan vocab REST, tetapi tidak ada dukungan data terkait.

5. membangun sistem berlapis untuk meningkatkan skalabilitas

   Sistem REST terdiri dari lapisan hierarkis. Setiap lapisan berisi komponen yang menggunakan layanan komponen yang berada di lapisan berikutnya di bawah ini. Jadi Anda dapat menambahkan lapisan dan komponen baru dengan mudah.

   Misalnya ada lapisan klien yang berisi klien dan di bawahnya ada lapisan layanan yang berisi layanan tunggal. Sekarang Anda dapat menambahkan cache sisi klien di antara mereka. Setelah itu Anda dapat menambahkan contoh layanan lain dan penyeimbang beban, dan seterusnya ... Kode klien dan kode layanan tidak akan berubah.

6. kode sesuai permintaan untuk memperluas fungsionalitas klien

   Batasan ini bersifat opsional. Misalnya Anda dapat mengirim parser untuk jenis media tertentu ke klien, dan seterusnya ... Untuk melakukan ini, Anda mungkin memerlukan sistem pemuat plugin standar di klien, atau klien Anda akan digabungkan ke solusi pemuat plugin .

Kendala REST menghasilkan sistem yang sangat skalabel di mana klien dipisahkan dari implementasi layanan. Jadi klien dapat digunakan kembali, umum seperti browser di web. Klien dan layanan memiliki standar dan vocab yang sama, sehingga mereka dapat saling memahami walaupun faktanya klien tidak mengetahui detail implementasi layanan. Hal ini memungkinkan untuk membuat klien otomatis yang dapat menemukan dan memanfaatkan layanan REST untuk mencapai tujuan mereka. Dalam jangka panjang, klien ini dapat berkomunikasi satu sama lain dan saling mempercayai dengan tugas, seperti halnya manusia. Jika kami menambahkan pola pembelajaran ke klien tersebut, maka hasilnya akan menjadi satu atau lebih AI menggunakan web mesin, bukan taman server tunggal. Jadi pada akhirnya mimpi Berners Lee: web semantik dan kecerdasan buatan akan menjadi kenyataan. Jadi pada tahun 2030 kita berakhir dengan Skynet. Sampai saat itu ... ;-)

RESTful (Representational state transfer) Pemrograman API adalah menulis aplikasi web dalam bahasa pemrograman apa pun dengan mengikuti 5 prinsip perangkat lunak gaya arsitektur dasar:

1. Sumberdaya (data, informasi).
2. Pengidentifikasi global unik (semua sumber daya diidentifikasi unik oleh URI ).
3. Antarmuka seragam - gunakan antarmuka sederhana dan standar (HTTP).
4. Representasi - semua komunikasi dilakukan oleh perwakilan (mis. XML / JSON )
5. Stateless (setiap permintaan terjadi dalam isolasi lengkap, lebih mudah untuk melakukan cache dan load-balance),

Dengan kata lain Anda sedang menulis aplikasi jaringan point-to-point sederhana melalui HTTP yang menggunakan kata kerja seperti GET, POST, PUT atau DELETE dengan mengimplementasikan RESTful architecture yang mengusulkan standardisasi antarmuka yang diekspos setiap "sumber daya". Tidak ada yang menggunakan fitur web saat ini dalam cara yang sederhana dan efektif (arsitektur yang sangat sukses, terbukti dan didistribusikan). Ini adalah alternatif untuk mekanisme yang lebih kompleks seperti SOAP , CORBA dan RPC .

Pemrograman yang tenang sesuai dengan desain arsitektur Web dan, jika diimplementasikan dengan benar, ini memungkinkan Anda untuk mengambil keuntungan penuh dari infrastruktur Web yang dapat diskalakan.

Jika saya harus mengurangi disertasi asli pada REST menjadi hanya 3 kalimat pendek, saya pikir yang berikut menangkap esensinya:

1. Sumber daya diminta melalui URL.
2. Protokol terbatas pada apa yang dapat Anda komunikasikan dengan menggunakan URL.
3. Metadata dilewatkan sebagai pasangan nama-nilai (memposting data dan parameter string kueri).

Setelah itu, mudah untuk terlibat dalam perdebatan tentang adaptasi, konvensi pengkodean, dan praktik terbaik.

Menariknya, tidak disebutkan operasi HTTP POST, GET, DELETE, atau PUT dalam disertasi ini. Itu harus menjadi interpretasi seseorang kemudian tentang "praktik terbaik" untuk "antarmuka yang seragam".

Ketika datang ke layanan web, tampaknya kita memerlukan beberapa cara untuk membedakan arsitektur berbasis WSDL dan SOAP yang menambah overhead yang besar dan kompleksitas yang mungkin tidak perlu banyak untuk antarmuka. Mereka juga membutuhkan kerangka kerja tambahan dan alat pengembang untuk dapat diimplementasikan. Saya tidak yakin apakah REST adalah istilah terbaik untuk membedakan antara antarmuka akal sehat dan antarmuka yang terlalu banyak direkayasa seperti WSDL dan SOAP. Tapi kita butuh sesuatu.

REST adalah pola arsitektur dan gaya penulisan aplikasi terdistribusi. Ini bukan gaya pemrograman dalam arti sempit.

Mengatakan Anda menggunakan gaya REST mirip dengan mengatakan bahwa Anda membangun rumah dengan gaya tertentu: misalnya Tudor atau Victoria. Baik REST sebagai gaya perangkat lunak dan Tudor atau Victoria sebagai gaya rumah dapat ditentukan oleh kualitas dan kendala yang membentuknya. Misalnya REST harus memiliki pemisahan Server Klien di mana pesan menggambarkan diri sendiri. Rumah bergaya Tudor memiliki atap dan Atap yang tumpang tindih yang curam dengan atap yang menghadap ke depan. Anda dapat membaca disertasi Roy untuk mempelajari lebih lanjut tentang kendala dan kualitas yang membentuk REST.

REST tidak seperti gaya rumah yang mengalami kesulitan diterapkan secara konsisten dan praktis. Ini mungkin disengaja. Meninggalkan implementasi aktualnya hingga ke perancang. Jadi Anda bebas untuk melakukan apa yang Anda inginkan selama Anda memenuhi kendala yang ditetapkan dalam disertasi Anda membuat Sistem REST.

Bonus:

Seluruh web didasarkan pada REST (atau REST didasarkan pada web). Karena itu sebagai pengembang web, Anda mungkin ingin mengetahui hal itu meskipun tidak perlu menulis aplikasi web yang bagus.

Inilah garis dasar REST saya. Saya mencoba untuk menunjukkan pemikiran di balik masing-masing komponen dalam arsitektur RESTful sehingga memahami konsep lebih intuitif. Semoga ini membantu menghilangkan mitos REST bagi sebagian orang!

REST (Representational State Transfer) adalah arsitektur desain yang menguraikan bagaimana sumber daya jaringan (yaitu node yang berbagi informasi) dirancang dan ditangani. Secara umum, arsitektur RESTful membuatnya sehingga klien (mesin yang meminta) dan server (mesin yang merespons) dapat meminta untuk membaca, menulis, dan memperbarui data tanpa klien harus tahu bagaimana server beroperasi dan server dapat lewat kembali tanpa perlu tahu apa-apa tentang klien. Oke, keren ... tapi bagaimana kita melakukan ini dalam praktek?

• Persyaratan yang paling jelas adalah bahwa perlu ada semacam bahasa universal sehingga server dapat memberi tahu klien apa yang ingin dilakukan dengan permintaan dan agar server merespons.

• Tetapi untuk menemukan sumber daya yang diberikan dan kemudian memberi tahu klien di mana sumber daya itu hidup, perlu ada cara universal untuk menunjuk sumber daya. Di sinilah Universal Resource Identifiers (URI) masuk; mereka pada dasarnya adalah alamat unik untuk menemukan sumber daya.

Tetapi arsitektur REST tidak berakhir di sana! Sementara hal di atas memenuhi kebutuhan dasar dari apa yang kita inginkan, kami juga ingin memiliki arsitektur yang mendukung lalu lintas volume tinggi karena server mana pun biasanya menangani respons dari sejumlah klien. Dengan demikian, kami tidak ingin membanjiri server dengan mengingat informasi tentang permintaan sebelumnya.

• Oleh karena itu, kami memberlakukan batasan bahwa setiap pasangan permintaan-respons antara klien dan server independen, artinya server tidak harus mengingat apa pun tentang permintaan sebelumnya (keadaan sebelumnya dari interaksi client-server) untuk menanggapi yang baru permintaan. Ini berarti bahwa kami ingin interaksi kami tanpa kewarganegaraan.

• Untuk lebih memudahkan ketegangan pada server kami dari mengulangi perhitungan yang telah dilakukan baru-baru ini untuk klien tertentu, REST juga memungkinkan caching. Pada dasarnya, caching berarti mengambil snapshot dari respons awal yang diberikan kepada klien. Jika klien membuat permintaan yang sama lagi, server dapat memberikan snapshot klien daripada mengulang semua perhitungan yang diperlukan untuk membuat respons awal. Namun, karena ini adalah snapshot, jika snapshot belum kedaluwarsa - server menetapkan waktu kedaluwarsa di muka - dan respons telah diperbarui sejak cache awal (yaitu permintaan akan memberikan jawaban yang berbeda dari respons yang di-cache) , klien tidak akan melihat pembaruan hingga cache kedaluwarsa (atau cache dihapus) dan respons diberikan dari awal lagi.

• Hal terakhir yang sering Anda dapatkan tentang arsitektur ISTIRAHAT adalah arsitekturnya berlapis. Kami sebenarnya sudah secara implisit mendiskusikan persyaratan ini dalam diskusi kami tentang interaksi antara klien dan server. Pada dasarnya, ini berarti bahwa setiap lapisan dalam sistem kami hanya berinteraksi dengan lapisan yang berdekatan. Jadi dalam diskusi kami, lapisan klien berinteraksi dengan lapisan server kami (dan sebaliknya), tetapi mungkin ada lapisan server lain yang membantu server utama memproses permintaan yang klien tidak berkomunikasi secara langsung. Sebaliknya, server meneruskan permintaan sebagaimana diperlukan.

Sekarang, jika semua ini terdengar familier, maka hebat. Hypertext Transfer Protocol (HTTP), yang mendefinisikan protokol komunikasi melalui World Wide Web adalah implementasi gagasan abstrak arsitektur RESTful (atau turunan dari kelas REST jika Anda seorang fanatik OOP seperti saya). Dalam implementasi REST ini, klien dan server berinteraksi melalui GET, POST, PUT, DELETE, dll., Yang merupakan bagian dari bahasa universal dan sumber daya dapat diarahkan menggunakan URL.

Saya pikir intinya adalah pemisahan status ke dalam lapisan yang lebih tinggi sementara menggunakan internet (protokol) sebagai lapisan transpor stateless . Kebanyakan pendekatan lain mencampurkan segalanya.

Ini merupakan pendekatan praktis terbaik untuk menangani perubahan mendasar pemrograman di era internet. Mengenai perubahan mendasar, Erik Meijer berdiskusi di acara di sini: http://www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197 . Dia merangkumnya sebagai lima efek, dan menyajikan solusi dengan merancang solusi ke dalam bahasa pemrograman. Solusinya, bisa juga dicapai di level platform atau sistem, terlepas dari bahasanya. Yang tenang dapat dilihat sebagai salah satu solusi yang telah sangat sukses dalam praktik saat ini.

Dengan gaya tenang, Anda mendapatkan dan memanipulasi keadaan aplikasi di internet yang tidak dapat diandalkan. Jika gagal operasi saat ini untuk mendapatkan keadaan yang benar dan saat ini, perlu prinsip validasi nol untuk membantu aplikasi untuk melanjutkan. Jika gagal memanipulasi negara, biasanya menggunakan beberapa tahap konfirmasi untuk menjaga semuanya tetap benar. Dalam hal ini, istirahat itu sendiri bukanlah solusi keseluruhan, ia membutuhkan fungsi di bagian lain dari tumpukan aplikasi web untuk mendukung kerjanya.

Dengan sudut pandang ini, gaya lainnya tidak benar-benar terkait dengan internet atau aplikasi web. Ini adalah solusi mendasar untuk banyak situasi pemrograman. Tidak sederhana juga, itu hanya membuat antarmuka sangat sederhana, dan mengatasi teknologi lain dengan sangat baik.

Hanya 2c saya.

Sunting: Dua aspek lebih penting:

• Statelessness menyesatkan. Ini tentang API yang tenang, bukan aplikasi atau sistem. Sistem harus stateful. Desain yang tenang adalah tentang merancang sistem stateful berdasarkan API stateless. Beberapa kutipan dari QA lain :

  • REST, beroperasi pada representasi sumber daya, masing-masing diidentifikasi dengan URL. Ini biasanya bukan objek data, tetapi objek kompleks abstraksi .
  • REST adalah singkatan dari "transfer negara representasional", yang berarti ini semua tentang berkomunikasi dan memodifikasi keadaan beberapa sumber daya dalam suatu sistem.

• Idempotence : Bagian REST yang sering diabaikan adalah idempotensi sebagian besar kata kerja. Itu mengarah ke sistem yang kuat dan kurang saling ketergantungan interpretasi yang tepat dari semantik .

Ini adalah "diskusi" yang luar biasa panjang, namun cukup membingungkan untuk sedikitnya.

IMO:

1) Tidak ada yang namanya pemrograman yang tenang, tanpa sambungan yang besar dan banyak bir :)

2) Representational State Transfer (REST) ​​adalah gaya arsitektur yang ditentukan dalam disertasi Roy Fielding . Ia memiliki sejumlah kendala. Jika Layanan Anda / Klien menghormati mereka maka itu TETAP. Ini dia.

Anda dapat meringkas (secara signifikan) kendala untuk:

• komunikasi tanpa kewarganegaraan
• menghormati spesifikasi HTTP (jika HTTP digunakan)
• mengkomunikasikan format konten yang dikirimkan dengan jelas
• menggunakan hypermedia sebagai mesin status aplikasi

Ada posting lain yang sangat bagus yang menjelaskan semuanya dengan baik.

Banyak jawaban menyalin / menempel informasi yang valid mencampurnya dan menambahkan beberapa kebingungan. Orang-orang berbicara di sini tentang level, tentang RESTFul URI (tidak ada hal seperti itu!), Menerapkan metode HTTP GET, POST, PUT ... REST bukan tentang itu atau tidak hanya tentang itu.

Misalnya tautan - senang memiliki API yang terlihat indah tetapi pada akhirnya klien / server tidak terlalu peduli dengan tautan yang Anda dapatkan / kirim itu adalah konten yang penting.

Pada akhirnya, setiap klien RESTful harus dapat menggunakan layanan RESTful apa pun selama format konten diketahui.

Pertanyaan lama, cara menjawab yang agak baru. Ada banyak kesalahpahaman di luar sana tentang konsep ini. Saya selalu berusaha mengingat:

1. URL terstruktur dan Metode Http / Verba bukan definisi pemrograman yang tenang.
2. JSON bukan pemrograman yang tenang
3. Pemrograman yang tenang bukan untuk API

Saya mendefinisikan pemrograman yang tenang sebagai

Aplikasi gelisah jika menyediakan sumber daya (menjadi kombinasi kontrol transisi data + keadaan) dalam jenis media yang dipahami klien

Untuk menjadi programmer yang tenang Anda harus mencoba untuk membangun aplikasi yang memungkinkan aktor untuk melakukan sesuatu. Bukan hanya mengekspos database.

Kontrol transisi negara hanya masuk akal jika klien dan server menyetujui jenis representasi media dari sumber daya. Kalau tidak, tidak ada cara untuk mengetahui apa itu kontrol dan apa yang tidak dan bagaimana menjalankan kontrol. Yaitu jika browser tidak tahu <form>tag dalam html maka tidak ada yang bisa Anda kirimkan ke keadaan transisi di browser Anda.

Saya tidak mencari untuk mempromosikan diri, tetapi saya memperluas ide-ide ini secara mendalam dalam pembicaraan saya http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html .

Kutipan dari ceramah saya adalah tentang model richardson maturity yang sering disebut, saya tidak percaya pada level, Anda baik RESTful (level 3) atau Anda tidak, tetapi apa yang saya suka sebutkan tentang itu adalah apa level masing-masing tidak untuk Anda dalam perjalanan ke RESTful

REST mendefinisikan 6 kendala arsitektur yang membuat layanan web apa pun - API RESTful yang sebenarnya .

1. Antarmuka yang seragam
2. Server klien
3. Tanpa kewarganegaraan
4. Cacheable
5. Sistem berlapis
6. Kode sesuai permintaan (opsional)

https://restfulapi.net/rest-architectural-constraints/

REST === Analogi HTTP tidak benar sampai Anda tidak menekankan fakta bahwa "HARUS" digerakkan oleh HATEOAS .

Roy sendiri yang membersihkannya di sini .

REST API harus dimasukkan tanpa pengetahuan sebelumnya di luar URI awal (bookmark) dan sekumpulan jenis media terstandar yang sesuai untuk audiens yang dituju (yaitu, diharapkan dipahami oleh klien mana pun yang mungkin menggunakan API). Sejak saat itu, semua transisi status aplikasi harus didorong oleh pemilihan klien dari pilihan yang disediakan server yang hadir dalam representasi yang diterima atau tersirat oleh manipulasi pengguna dari representasi tersebut. Transisi dapat ditentukan (atau dibatasi oleh) pengetahuan klien tentang jenis media dan mekanisme komunikasi sumber daya, yang keduanya dapat ditingkatkan dengan cepat (misalnya, kode sesuai permintaan).

[Kegagalan di sini menyiratkan bahwa informasi out-of-band mendorong interaksi bukannya hiperteks.]

REST adalah gaya arsitektur yang didasarkan pada standar web dan protokol HTTP (diperkenalkan pada tahun 2000).

Dalam arsitektur berbasis REST, semuanya adalah sumber daya (Pengguna, Pesanan, Komentar). Sumber daya diakses melalui antarmuka umum berdasarkan metode standar HTTP (GET, PUT, PATCH, DELETE dll).

Dalam arsitektur berbasis REST Anda memiliki server REST yang menyediakan akses ke sumber daya. Klien REST dapat mengakses dan memodifikasi sumber daya REST.

Setiap sumber daya harus mendukung operasi umum HTTP. Sumber daya diidentifikasi oleh ID global (yang biasanya URI).

REST memungkinkan sumber daya memiliki representasi yang berbeda, misalnya, teks, XML, JSON dll. Klien REST dapat meminta representasi spesifik melalui protokol HTTP (negosiasi konten).

Metode HTTP:

Metode PUT, GET, POST dan DELETE adalah tipikal yang digunakan dalam arsitektur berbasis REST. Tabel berikut ini memberikan penjelasan tentang operasi ini.

• GET mendefinisikan akses membaca sumber daya tanpa efek samping. Sumber daya tidak pernah diubah melalui permintaan GET, misalnya, permintaan tidak memiliki efek samping (idempoten).
• PUT menciptakan sumber daya baru. Itu juga harus idempoten.
• HAPUS menghapus sumber daya. Operasi idempoten. Mereka dapat diulang tanpa mengarah ke hasil yang berbeda.
• POST memperbarui sumber daya yang ada atau membuat sumber daya baru.

REST adalah singkatan dari transfer perwakilan negara .

Itu bergantung pada protokol komunikasi yang tidak stateless, client-server, cacheable - dan dalam semua kasus, protokol HTTP digunakan.

REST sering digunakan dalam aplikasi mobile, situs web jejaring sosial, alat mashup dan proses bisnis otomatis. Gaya REST menekankan bahwa interaksi antara klien dan layanan ditingkatkan dengan memiliki sejumlah operasi (kata kerja) yang terbatas. Fleksibilitas disediakan dengan menetapkan sumber daya (kata benda) indikator sumber daya universal (URI) mereka sendiri yang unik.

Pengantar tentang Istirahat

Berbicara lebih dari sekadar bertukar informasi . Protokol sebenarnya dirancang sehingga tidak ada pembicaraan yang harus terjadi. Setiap pihak tahu apa pekerjaan khusus mereka karena ditentukan dalam protokol. Protokol memungkinkan pertukaran informasi murni dengan mengorbankan setiap perubahan dalam tindakan yang mungkin. Berbicara, di sisi lain, memungkinkan satu pihak untuk bertanya tindakan apa lagi yang dapat diambil dari pihak lain. Mereka bahkan dapat mengajukan pertanyaan yang sama dua kali dan mendapatkan dua jawaban yang berbeda, karena Negara pihak lain mungkin telah berubah untuk sementara. Berbicara adalah arsitektur yang tenang . Tesis Fielding menentukan arsitektur yang harus diikuti jika seseorang ingin memungkinkan mesin untuk berbicara satu sama lain daripada hanyaberkomunikasi .

Tidak ada gagasan seperti "RESTful programming" per se. Akan lebih baik disebut paradigma RESTful atau bahkan arsitektur RESTful yang lebih baik. Ini bukan bahasa pemrograman. Itu adalah paradigma.

Dari Wikipedia :

Dalam komputasi, transfer status representasional (REST) ​​adalah gaya arsitektur yang digunakan untuk pengembangan web.

Intinya adalah bahwa jika kita setuju untuk menggunakan bahasa umum untuk operasi dasar (kata kerja http), infrastruktur dapat dikonfigurasi untuk memahaminya dan mengoptimalkannya dengan benar, misalnya, dengan menggunakan header caching untuk mengimplementasikan caching sama sekali level.

Dengan operasi GET yang diimplementasikan dengan benar, tidak masalah jika informasi tersebut berasal dari DB server Anda, memcache server Anda, CDN, cache proxy, cache browser Anda atau penyimpanan lokal browser Anda. Sumber up to date puasa, paling mudah tersedia dapat digunakan.

Mengatakan bahwa Rest hanyalah perubahan sintaksis dari menggunakan permintaan GET dengan parameter tindakan untuk menggunakan kata kerja http yang tersedia membuatnya tampak seperti tidak memiliki manfaat dan murni kosmetik. Intinya adalah menggunakan bahasa yang dapat dipahami dan dioptimalkan oleh setiap bagian dari rantai. Jika operasi GET Anda memiliki tindakan dengan efek samping, Anda harus melewati semua caching HTTP atau Anda akan berakhir dengan hasil yang tidak konsisten.

Apa itu Pengujian API ?

Pengujian API menggunakan pemrograman untuk mengirim panggilan ke API dan mendapatkan hasilnya. Pengujian menganggap segmen yang diuji sebagai kotak hitam. Tujuan pengujian API adalah untuk mengkonfirmasi eksekusi yang tepat dan perawatan yang salah dari bagian sebelum koordinasinya dalam suatu aplikasi.

API SISA

REST: Transfer Negara Representasi.

• Ini adalah pengaturan fungsi di mana penguji melakukan permintaan dan menerima tanggapan. Dalam REST API, interaksi dilakukan melalui protokol HTTP.
• REST juga memungkinkan komunikasi antara komputer satu sama lain melalui jaringan.
• Untuk mengirim dan menerima pesan, ini menggunakan metode HTTP, dan tidak memerlukan definisi pesan yang ketat, tidak seperti layanan Web.
• Pesan REST sering menerima formulir baik dalam bentuk XML, atau JavaScript Object Notation (JSON).

4 Metode API yang Umum Digunakan: -

1. DAPATKAN: - Ini memberikan akses hanya baca ke sumber daya.
2. POST: - Digunakan untuk membuat atau memperbarui sumber daya baru.
3. PUT: - Digunakan untuk memperbarui atau mengganti sumber daya yang ada atau membuat sumber daya baru.
4. HAPUS: - Digunakan untuk menghapus sumber daya.

Langkah-langkah untuk Menguji API Secara Manual: -

Untuk menggunakan API secara manual, kita dapat menggunakan plugin REST API berbasis browser.

1. Pasang plugin POSTMAN (Chrome) / REST (Firefox)
2. Masukkan URL API
3. Pilih metode REST
4. Pilih content-Header
5. Masukkan Permintaan JSON (POST)
6. Klik kirim
7. Ini akan mengembalikan respons keluaran

Langkah-langkah untuk Mengotomatiskan REST API

Ini sangat kurang disebutkan di mana-mana tetapi Model Kedewasaan Richardson adalah salah satu metode terbaik untuk benar-benar menilai seberapa Restful API seseorang. Lebih lanjut di sini:

Model Kematangan Richardson

Saya akan mengatakan bahwa blok bangunan penting dalam memahami REST terletak pada titik akhir atau pemetaan, seperti /customers/{id}/balance.

Anda dapat membayangkan titik akhir tersebut sebagai pipa penghubung dari situs web (front-end) ke database / server Anda (back-end). Dengan menggunakannya, ujung-depan dapat melakukan operasi ujung-belakang yang ditentukan dalam metode yang sesuai dari pemetaan REST apa pun dalam aplikasi Anda.