Beberapa konsep yang berkaitan dengan konflik REST di kepala saya ketika saya mencoba menerapkannya.
Saya memiliki sistem API back-end REST-ful yang memegang logika bisnis, dan aplikasi web yang menyediakan UI. Dari berbagai sumber tentang REST (khususnya, REST dalam Praktek: Hypermedia dan Arsitektur Sistem ) saya tahu bahwa saya tidak boleh mengekspos pengidentifikasi mentah entitas saya, melainkan mengembalikan hyperlink dengan rel="self".
Perhatikan contohnya. Api REST memiliki sumber daya yang mengembalikan seseorang:
<Person>
<Links>
<Link rel="self" href="http://my.rest.api/api/person/1234"/>
</Links>
<Pets>
<Link rel="pet" href="http://my.rest.api/api/pet/678"/>
</Pets>
</Person>
Masalah muncul dengan aplikasi web. Mari kita asumsikan itu mengembalikan halaman yang berisi hyperlink ke browser:
<body class="person">
<p>
<a href="http://my.web.app/pet/???????" />
</p>
</body>
Apa yang harus saya masukkan ke hrefatribut? Bagaimana cara saya menjaga URL entitas API di aplikasi web agar bisa mendapatkan entitas ketika pengguna membuka halaman target?
Persyaratannya tampaknya saling bertentangan:
- Hyperlink
hrefharus mengarah ke aplikasi web karena itu adalah sistem hosting UI - The
hrefharus memiliki beberapa id entitas karena aplikasi web harus mampu mengatasi entitas ketika halaman target terbuka - Aplikasi web seharusnya tidak mem-parsing / membuat URL REST karena itu bukan REST-ful, buku tersebut mengatakan
URI harus buram bagi konsumen. Hanya penerbit URI yang tahu bagaimana menafsirkannya dan memetakannya ke sumber daya.
Jadi, saya tidak bisa hanya mengambil 1234dari URL respons API karena sebagai klien yang tenang saya harus memperlakukannya seolah-olah itu seperti sesuatu http://my.rest.api/api/AGRIDd~ryPQZ^$RjEL0j. Di sisi lain, saya harus memberikan beberapa URL yang mengarah ke aplikasi web saya dan cukup bagi aplikasi untuk mengembalikan URL asli API dan menggunakan URL itu untuk mengakses sumber daya API.
Cara paling sederhana mungkin hanya menggunakan URL sumber daya API sebagai pengidentifikasi string mereka. Tetapi url halaman web seperti http://my.web.app/person/http%3A%2F%2Fmy.rest.api%2Fapi%2Fperson%2F1234itu jelek.
Itu semua tampaknya cukup mudah untuk aplikasi desktop atau aplikasi javascript satu halaman. Karena mereka hidup terus menerus, mereka hanya dapat menyimpan URL dalam memori bersama dengan objek layanan untuk masa aplikasi dan menggunakannya saat diperlukan.
Dengan aplikasi web saya bisa membayangkan beberapa pendekatan, tetapi semuanya tampak aneh:
- Ganti host di URL API dan simpan hasilnya saja. Kelemahan besar adalah bahwa itu memerlukan aplikasi web untuk menangani URL apa pun yang dihasilkan API, yang berarti kopling mengerikan. Selain itu, ini tidak tenang lagi, karena aplikasi web saya mulai menafsirkan URL.
- Paparkan id mentah di REST API bersama dengan tautan, gunakan untuk membuat URL Aplikasi Web, dan kemudian gunakan id di server aplikasi web untuk menemukan sumber daya yang diperlukan dalam API. Ini lebih baik, tetapi akan mempengaruhi kinerja server aplikasi web karena aplikasi web harus melalui navigasi layanan REST yang mengeluarkan rantai permintaan get-by-id dari beberapa formulir untuk menangani permintaan dari browser. Untuk sumber daya yang agak bersarang ini mungkin mahal.
- Simpan semua
selfURL yang dikembalikan oleh api dalam pemetaan persisten (DB?) Di server aplikasi web. Buat beberapa id untuk mereka, gunakan id untuk membangun URL halaman aplikasi web dan untuk mendapatkan URL sumber daya layanan REST. Yaitu saya menyimpanhttp://my.rest.api/pet/678URL di suatu tempat dengan kunci baru, katakanlah3, dan hasilkan URL halaman web sebagaihttp://my.web.app/pet/3. Ini terlihat seperti implementasi HTTP Cache. Saya tidak tahu mengapa, tapi itu terasa aneh bagi saya.
Atau Apakah itu semua berarti bahwa RESTful API tidak dapat berfungsi sebagai backend untuk aplikasi web?