RESTful API dengan # perluasan fragmen di Templat URI (RFC 6570)

Saya memiliki spesifikasi API RESTful untuk proyek baru dari perusahaan lain dan ini mengacu pada RFC6570 dan penggunaan Ekspansi Fragmen {#var} di Templat URI saat membuat permintaan ke API mereka.

Templat URI terlihat seperti:

PUT https://api.acme.com/order{#meta*}{?order_number} atau GET https://api.acme.com/orders{#meta*} (perhatikan perbedaannya dengan pesanan/pesanan).

Mereka menyebutkan 'jika metadata yang disimpan di sistem Anda terlihat seperti ini:'

{
  "meta": {
    "customer": "1234",
    "state": "open"
  },
  "order_number": "0003"
}

Ini kemudian diterjemahkan ke dalam permintaan seperti PUT https://api.acme.com/order#customer=1234,state=open?order_number=0003 atau GET https://api.acme.com/orders#customer=1234,state=open.

Fragmen URL, mis. #customer=1234,state=open dimaksudkan untuk digunakan sebagai semacam pemfilteran metadata atau konteks permintaan?

Permintaan tukang pos, curl dan browser tampaknya menghapus semuanya setelah # sebelum dikirim ke server. Apakah itu perilaku yang diharapkan dan dijelaskan dalam RFC di suatu tempat? Apakah itu berarti URL RESTful ini tidak valid?

Apa kasus penggunaan yang tepat untuk perluasan fragmen {#var} di Templat URL?


rest restful-url rfc
person DLT    schedule 07.10.2020    source sumber
comment
Kami telah menemukan tools.ietf.org/html/rfc7230#section-5.1 yang menyatakan URI target mengecualikan komponen fragmen referensi, jika ada, karena pengidentifikasi fragmen dicadangkan untuk pemrosesan sisi klien dan tools.ietf.org/html/rfc3986#section-3.5 yang menyatakan Komponen kueri ditunjukkan dengan karakter tanda tanya pertama (?) dan diakhiri dengan karakter tanda angka (#). Saya berasumsi ini berarti URL tidak valid dari sudut pandang RFC, masih ingin tahu apakah # Fragment Expansion masuk akal dalam desain RESTful dan/atau kasus penggunaan yang dimaksudkan.   -  person DLT    schedule 08.10.2020

Jawaban (1)


arrow_upward
1
arrow_downward

Permintaan tukang pos, curl, dan browser tampaknya menghapus semuanya setelah # sebelum dikirim ke server. Apakah itu perilaku yang diharapkan dan dijelaskan dalam RFC di suatu tempat?

Ya, hal ini dijelaskan dalam RFC 3896

pengidentifikasi fragmen tidak digunakan dalam pemrosesan URI yang spesifik skema; sebaliknya, pengidentifikasi fragmen dipisahkan dari URI lainnya sebelum dilakukan dereferensi, sehingga informasi pengidentifikasi dalam fragmen itu sendiri hanya didereferensi oleh agen pengguna, apa pun skema URI-nya.

Ide yang sama, seperti yang dijelaskan oleh RFC 7230

Apakah itu berarti URL RESTful ini tidak valid?

Semacam itu.

https://api.acme.com/orders#customer=1234,state=open

Itu adalah URL yang benar-benar valid (lihat aturan produksi di RFC 3986 lampiran A) .

Mari kita tinjau spesifikasi untuk fragmen:

Komponen pengidentifikasi fragmen dari URI memungkinkan identifikasi tidak langsung dari sumber daya sekunder dengan mengacu pada sumber daya utama dan informasi pengidentifikasi tambahan. Sumber daya sekunder yang teridentifikasi dapat berupa sebagian atau subset dari sumber daya primer, pandangan mengenai representasi sumber daya primer, atau sumber daya lain yang didefinisikan atau dijelaskan oleh representasi tersebut.

Definisi HTTP sedikit lebih jelas:

Komponen fragmen opsional memungkinkan identifikasi tidak langsung dari sumber daya sekunder

Jadi untuk latihan, mari kita lihat identifier untuk spesifikasi fragmen itu sendiri

https://tools.ietf.org/html/rfc3986#section-3.5

Apa yang kita miliki di sini adalah pengidentifikasi untuk dua sumber daya: sumber daya utama adalah halaman web itu sendiri, yang diidentifikasi oleh urutan karakter sebelum pembatas fragmen -- https://tools.ietf.org/html/rfc3986 ; lalu kita memiliki sumber daya sekunder di dalam sumber daya utama tersebut, section-3.5 memberi tahu kita apa yang harus dicari dalam sumber daya utama. Jadi browser mengetahui untuk (a) mengunduh sumber daya utama, dan kemudian (b) setelah menemukan bahwa sumber daya utama memiliki representasi text/html, mengetahui cara menggali tag html untuk menemukan tag yang cocok dengan fragmen. Browser kemudian dapat melompat langsung ke lokasi yang benar dalam dokumen.

Dalam contoh Anda, https://api.acme.com/orders adalah sumber daya utama, dan customer=1234,state=open adalah fragmen yang digunakan untuk mengidentifikasi beberapa sumber daya dalam representasi sumber daya utama.

TETAPI

RFC 7230 mendefinisikan baris permintaan HTTP

method SP request-target SP HTTP-version CRLF

Dimana request-target pada gilirannya didefinisikan sebagai

     request-target = origin-form
                    / absolute-form
                    / authority-form
                    / asterisk-form

Dua yang menarik bagi kami adalah origin-form dan bentuk absolut. Keduanya ditentukan oleh RFC 7230

origin-form    = absolute-path [ "?" query ]
absolute-form  = absolute-URI

di mana absolute-URI didefinisikan dalam RFC 3986

Beberapa elemen protokol hanya mengizinkan bentuk absolut dari URI tanpa pengidentifikasi fragmen.

absolute-URI  = scheme ":" hier-part [ "?" query ]

Hal ini sesuai dengan pembatasan pada target-uri

URI target mengecualikan komponen fragmen referensi, jika ada, karena pengidentifikasi fragmen dicadangkan untuk pemrosesan sisi klien

Kasus penggunaan apa yang tepat untuk perluasan fragmen {#var} di Templat URL?

Mencoba membuat tautan ke sumber daya sekunder, khususnya sebagai kolaborasi dua potong kode; satu bagian pengkodean mengetahui nilai-nilai untuk variabel templat tetapi tidak mengetahui ke mana mereka seharusnya pergi (dan khususnya, variabel mana yang termasuk dalam fragmen), dan bagian kode lainnya mengetahui di mana dalam URI masing-masing variabel yang berbeda seharusnya berada untuk muncul, tetapi tidak mengetahui apa nilainya.

Dengan kata lain, hal yang sama persis seperti yang kita lakukan saat membuat templat URI untuk memungkinkan produksi pengidentifikasi sumber daya utama, namun juga memungkinkan perluasan variabel dalam elemen fragmen.

http://example.org/people/bob
http://example.org/people#bob
person VoiceOfUnreason    schedule 08.10.2020