REST API: header HTTP kustom vs parameter URL

97

Kapan Anda menggunakan header HTTP kustom di bagian permintaan REST API?

Contoh:

Apakah Anda pernah menggunakan

GET /orders/view 
(custom HTTP header) CLIENT_ID: 23

dari pada

GET /orders/view/client_id/23 or 
GET /orders/view/?client_id=23

http rest

— Vasile Cotovanu
sumber

124

URL menunjukkan sumber itu sendiri. A "klien" adalah sumber daya yang dapat ditindaklanjuti, sehingga harus menjadi bagian dari url dasar: /orders/view/client/23.

Parameter hanyalah itu, untuk membuat parameter akses ke sumber daya. Hal ini terutama datang ke dalam bermain dengan posting dan pencarian: /orders/find?q=blahblah&sort=foo. Ada garis tipis antara parameter dan sub-sumber: /orders/view/client/23/active versus /orders/view/client/23?show=active. Saya merekomendasikan gaya sub-resource dan parameter cadangan untuk pencarian.

Karena setiap titik akhir menunjukkan Transfer Status (untuk mengacaukan mnemonik), header kustom hanya boleh digunakan untuk hal-hal yang tidak melibatkan nama sumber daya (url), status sumber daya (badan), atau parameter secara langsung. mempengaruhi sumber daya (parameter). Itu meninggalkan metadata yang benar tentang permintaan untuk tajuk khusus.

HTTP memiliki banyak pilihan tajuk yang mencakup hampir semua yang Anda perlukan. Di mana saya telah melihat tajuk khusus muncul di sistem ke permintaan sistem yang beroperasi atas nama pengguna. Sistem proxy akan memvalidasi pengguna dan menambahkan " X-User: userid" ke tajuk dan menggunakan kredensial sistem untuk mencapai titik akhir. Sistem penerima memvalidasi bahwa kredensial sistem diotorisasi untuk bertindak atas nama pengguna, kemudian memvalidasi bahwa pengguna berwenang untuk melakukan tindakan tersebut.

— Nialscorva
sumber

Terima kasih atas jawaban yang komprehensif! Apakah Anda masih menggunakan X-User untuk API seluler di mana risiko memiliki proxy jahat (yang menghapus header) masih tinggi?

— Vasile Cotovanu

1

Tidak, penggunaan X-User yang saya sebutkan adalah dalam koneksi sistem ke sistem di mana sistem tersebut bertindak atas nama pihak ketiga. Misalnya, Pengguna U berbicara dengan Server A. Server A memberikan kredensial ke Server B dengan header X-User untuk mengatakan "Gunakan kredensial saya untuk memeriksa bahwa saya berwenang untuk melakukan tindakan ini atas nama Pengguna U." Ini muncul dalam Arsitektur Berorientasi Layanan, dan biasanya Anda menggunakan HTTPS. Platform seluler harus hampir selalu menjadi tindakan Pengguna itu sendiri, dan menggunakan kredensial orang pertama yang sesuai untuk transaksi.

— Nialscorva

7

Paragraf ketiga adalah salah satu jawaban paling informatif yang pernah saya baca di SO ;-)

— Alistair77

1

@Nialscorva Penjelasan bagus! bagaimana jika saya ingin pengguna berinteraksi dengan API saya melalui penampung resmi (seperti aplikasi seluler saya)? Apa yang saya lakukan sekarang adalah bahwa aplikasi seluler saya tidak diizinkan untuk melakukan tindakan apa pun sendiri dan tidak pula pengguna akhir .. kedua kredensial harus ada jika pengguna ingin melakukan tindakan.

— bolbol

6

Header kustom memiliki keuntungan sebagai berikut:

Dapat dibaca dengan mudah oleh alat / skrip jaringan (otentikasi, info meta, ...)
Menjaga url bebas dari hal-hal keamanan (lebih aman, bukan di cache browser / proxy)
Menjaga url lebih bersih: memungkinkan penyimpanan sumber daya yang lebih baik

— Christophe Roussy
sumber

mereka juga dapat

— dihilangkan

@fusi poin yang baik ... ini adalah topik tentang itu: stackoverflow.com/questions/20820572/…

— Christophe Roussy

5

Saya hanya akan menggunakan tajuk khusus jika tidak ada cara lain untuk menyampaikan informasi menurut standar atau konvensi. Darren102 menjelaskan cara umum untuk menyampaikan nilai itu. Api Anda akan jauh lebih bersahabat dengan menggunakan ayat pola tipikal menggunakan tajuk khusus. Itu tidak berarti Anda tidak memiliki alasan untuk menggunakannya, hanya saja mereka harus menjadi pilihan terakhir dan sesuatu yang belum ditangani oleh spesifikasi HTTP.

— menggugat
sumber

Setuju dengan sepenuh hati ... jangan pernah menemukan kembali roda jika ada cara standar untuk menyelesaikan tugas.

— Alessandro Santini

5

Kapan Anda menggunakan ... header HTTP di bagian permintaan dari REST API?

Otentikasi: GUID, otentikasi dasar, token khusus, dll. Misalnya, Otentikasi Dasar dengan token Panduan untuk api REST alih-alih nama pengguna / kata sandi

Jika Anda terlibat dalam penerusan token atau informasi seperti otentikasi lainnya antara domain yang dicakup oleh PCI-DSS atau aturan keamanan lainnya, Anda mungkin juga harus mengubur parameter karena beberapa peraturan secara eksplisit mewajibkan elemen otentikasi untuk menghindari URL yang dapat diputar ulang secara sepele (dari riwayat browser, log proxy, dll.).

— pengguna3038458
sumber

1

Tidak ada standar untuk REST, namun cara yang diterima adalah

GET /orders/view/23

Tidak menggunakan tajuk khusus dan karenanya tampilan 23 setelahnya diasumsikan sebagai id sehingga Anda akan memiliki fungsi yang mengambil id dan karenanya hanya menghasilkan informasi itu.

— darren102
sumber

1

Saya tidak akan menggunakan tajuk khusus karena Anda tidak tahu apakah ada proksi yang akan meneruskannya. Berbasis URL adalah caranya.

DAPATKAN / pesanan / lihat / klien / 23

— Antony Scott
sumber

1

Saya juga tidak akan merekomendasikan tajuk khusus, tetapi proxy yang rusak bukanlah alasannya. Proksi rusak itu harus diperbaiki.

— Julian Reschke

1

Pasti OK:

GET /orders/view/client_id/23 or 
GET /orders/view/?client_id=23

Juga Oke:

GET /orders/view/23 or

Saya pikir ini juga akan baik-baik saja:

POST /orders/view 
(custom HTTP header) CLIENT_ID: 23

— paulsm4
sumber

Respons REST-ful POST harus berupa HTTP 303 dengan header Lokasi disetel ke sesuatu seperti "/ orders / view / 23".

— Rich Remer

0

Anda dapat menggunakan tajuk khusus untuk menyertakan lebih banyak informasi tentang permintaan yang diproses sebagian mengingat Enveloping bukanlah praktik yang baik. Headernya aman .

— Anwar Husain
sumber