SISA API menggunakan POST bukan GET

Let's menganggap layanan ini menawarkan beberapa funcionality yang dapat saya gunakan seperti ini:

GET /service/function?param1=value1&param2=value2

Adalah benar untuk mengatakan bahwa aku bisa menggunakannya dengan POSTING query?

POST /service/function { param1 : value1, param2 : value2 }

Ada dua pertanyaan yang sama? Saya bisa menggunakan kedua varian dalam setiap kasus atau dokumentasi harus secara eksplisit mengatakan bahwa saya dapat menggunakan GET dan POST pertanyaan?

Mengomentari pertanyaan (6)

Hanya untuk review, SISA memiliki sifat-sifat tertentu yang pengembang harus diikuti dalam rangka untuk membuatnya Tenang:

Apa SISANYA?

Menurut wikipedia:

SISANYA gaya arsitektur yang menjelaskan sebagai berikut enam kendala diterapkan pada arsitektur, sementara meninggalkan pelaksanaan komponen individu bebas untuk desain:

  • Client–server: Server tidak peduli dengan antarmuka pengguna atau user negara, sehingga server dapat lebih sederhana dan lebih terukur.
  • Stateless: klien–server komunikasi lebih lanjut dibatasi oleh konteks klien yang disimpan di server antara permintaan.
  • Cacheable: Tanggapan harus, secara implisit atau eksplisit, mendefinisikan diri mereka sebagai cacheable, atau tidak, untuk mencegah klien menggunakan kembali basi atau tidak pantas data dalam menanggapi permintaan lebih lanjut.
  • sistem Berlapis: klien biasanya tidak dapat mengatakan apakah itu terhubung langsung ke end server, atau untuk perantara sepanjang jalan. Perantara server dapat meningkatkan sistem skalabilitas dengan mengaktifkan load-balancing dan dengan menyediakan shared cache.
  • Kode permintaan (opsional): Server sementara dapat memperluas atau menyesuaikan fungsi dari klien dengan transfer eksekusi kode.
  • interface yang Seragam: seragam antarmuka antara klien dan server, yang dibahas di bawah ini, menyederhanakan dan decouples arsitektur, yang memungkinkan masing-masing bagian untuk berkembang secara mandiri. (yaitu HTTP GET, POST, PUT, PATCH, HAPUS)

Apa kata kerja harus melakukan

JADI pengguna Daniel Vasallo melakukan pekerjaan yang baik meletakkan tanggung jawab dari metode ini di pertanyaan Pemahaman ISTIRAHAT: Verba, kode kesalahan, dan authentication:

Ketika berhadapan dengan Koleksi URI seperti: http://example.com/resources/

DAPATKAN: Daftar anggota koleksi, lengkap dengan anggota mereka Uri untuk lebih navigasi. Misalnya, list semua mobil yang dijual.

MASUKAN: Makna didefinisikan sebagai "menggantikan seluruh koleksi dengan yang lain koleksi".

POST:** Membuat entri baru di koleksi di mana ID secara otomatis dengan koleksi. ID yang dibuat biasanya disertakan sebagai bagian dari data yang dikembalikan oleh operasi ini.

MENGHAPUS: Makna didefinisikan sebagai "menghapus seluruh koleksi".

Jadi, untuk menjawab pertanyaan anda:

Apakah itu benar untuk mengatakan bahwa aku bisa menggunakannya dengan POSTING query? ...

ini Adalah dua pertanyaan yang sama? Saya bisa menggunakan kedua varian dalam setiap kasus atau dokumentasi harus secara eksplisit mengatakan bahwa saya dapat menggunakan GET dan POST pertanyaan?

Jika anda sedang menulis tua polos RPC API call, mereka bisa secara teknis dipertukarkan selama pemrosesan di sisi server yang tidak berbeda antara kedua panggilan. Namun, dalam rangka untuk panggilan untuk menjadi Tenang, menyebut endpoint melalui MENDAPATKAN metode harus memiliki fungsi yang berbeda (yang adalah untuk mendapatkan sumber daya(s)) dari POST metode (yang adalah untuk menciptakan sumber daya baru).

Catatan: ada beberapa perdebatan di luar sana tentang apakah atau tidak POST juga harus diizinkan untuk digunakan untuk memperbarui sumber daya... meskipun aku'm tidak mengomentari itu, saya'm hanya memberitahu anda beberapa orang memiliki masalah dengan itu.

Komentar (1)

Saya menggunakan POST tubuh untuk sesuatu yang non-sepele dan line-of-business apps untuk alasan-alasan ini:

  1. Keamanan - Jika kita menggunakan DAPATKAN dengan query string dan https, query string dapat disimpan dalam log server dan diteruskan sebagai link referral. Keduanya kini terlihat oleh server/network admin dan berikutnya domain pengguna pergi setelah meninggalkan aplikasi anda. Jadi jika kita mengirim query yang mengandung rahasia PII data seperti pelanggan's nama ini mungkin tidak diinginkan.
  2. URL panjang maksimum - Tidak ada masalah besar, tetapi beberapa browser yang memiliki batas pada panjang. Jadi jika kita memiliki beberapa item dalam url seperti query, paging, ladang untuk kembali, dll....
  3. Posting ini tidak cache secara default. Beberapa orang mengatakan caching yang diinginkan; namun, seberapa sering yang sama menetapkan kriteria pencarian yang tepat untuk objek yang sama persis pelanggan akan terjadi sebelum cache kali keluar sih?

BTW, saya juga menempatkan bidang untuk kembali di POSTING saya, tubuh saya mungkin tidak ingin mengekspos saya nama field. Keamanan adalah seperti bawang; banyak lapisan dan membuat kita menangis!

Komentar (5)
Larutan

Anda dapat't menggunakan API menggunakan POST atau MENDAPATKAN jika mereka tidak membangun untuk panggilan menggunakan metode ini separetly. Seperti jika anda mengatakan API

/service/function?param1=value1&param2=value2

diakses dengan menggunakan MENDAPATKAN metode. Maka anda tidak dapat menyebutnya menggunakan POST metode jika tidak ditetapkan sebagai POST metode oleh penciptanya. Jika anda melakukannya anda mungkin punya 405 Metode tidak diizinkan status.

Umumnya di POSTING metode yang anda butuhkan untuk mengirim konten ke dalam tubuh dengan format tertentu yang dijelaskan dalam content-type header untuk ex. application/json untuk data json.

Dan setelah itu permintaan tubuh akan deserialized di server akhir. Jadi, anda perlu untuk lulus serial data dari klien dan hal ini diputuskan oleh pengembang layanan.

Tapi secara umum istilah MENDAPATKAN digunakan ketika server mengembalikan beberapa data untuk klien dan tidak memiliki dampak apapun pada server sedangkan POST digunakan untuk membuat beberapa sumber daya pada server. Sehingga umumnya tidak harus sama.

Komentar (1)

Berpikir tentang hal itu. Ketika klien anda membuat MENDAPATKAN permintaan untuk sebuah URI X, apa itu's mengatakan ke server adalah: "aku ingin sebuah representasi dari resource yang terletak di X, dan operasi ini seharusnya't perubahan apa pun pada server." permintaan PUT mengatakan: "saya ingin anda untuk mengganti apapun adalah sumber daya yang terletak di X dengan entitas baru saya'm memberikan anda pada tubuh ini permintaan". HAPUS permintaan berkata: "saya ingin anda untuk menghapus apapun adalah sumber daya yang terletak di X". PATCH ini mengatakan "aku'm memberikan anda diff ini, dan anda harus mencoba untuk menerapkannya ke sumber daya di X dan memberitahu saya jika itu berhasil." Tapi POST mengatakan: "aku'm mengirimkan data ini subordinasi ke sumber daya di X, dan kami memiliki kesepakatan sebelumnya pada apa yang harus anda lakukan dengan itu."

Jika anda don't memilikinya didokumentasikan di suatu tempat bahwa sumber daya mengharapkan POS dan melakukan sesuatu dengan itu, itu doesn't masuk akal untuk mengirim POSTING ke mengharapkan untuk bertindak seperti MENDAPATKAN.

SISANYA bergantung pada standar perilaku yang mendasari protokol, dan POSTING lebih tepatnya metode yang digunakan untuk tindakan yang isn't standar. Hasil dari GET, PUT dan DELETE permintaan yang jelas dalam standar, tapi POSTING isn't. Hasil dari POST subordinasi ke server, jadi jika itu's tidak terdokumentasi yang dapat anda gunakan POST untuk melakukan sesuatu, anda harus berasumsi bahwa anda dapat't.

Komentar (0)

Itu bagus bahwa SISANYA membawa makna verba HTTP (seperti yang didefinisikan) tapi aku lebih memilih untuk setuju dengan Scott Peal.

Di sini juga item dari WIKI's diperpanjang penjelasan pada request POST:

Ada kalanya HTTP MENDAPATKAN kurang cocok bahkan untuk pengambilan data. Contoh dari hal ini adalah ketika banyak data yang akan ditentukan dalam URL. Browser dan web server dapat memiliki batas panjang URL yang akan menangani tanpa pemotongan atau kesalahan. Persen-encoding reserved karakter dalam Url dan query string dapat secara signifikan meningkatkan panjang mereka, dan sementara Apache HTTP Server dapat menangani hingga 4.000 karakter dalam URL,[5] Microsoft Internet Explorer terbatas untuk 2,048 karakter dalam URL.[6] sama-Sama, HTTP MENDAPATKAN tidak boleh digunakan di mana informasi sensitif seperti nama pengguna dan password, harus diserahkan bersama dengan data lainnya untuk permintaan untuk menyelesaikan. Bahkan jika HTTPS digunakan, mencegah data dari yang dicegat dalam perjalanan, sejarah browser dan web server's log akan berisi URL lengkap di plaintext, yang mungkin akan terkena jika salah satu sistem diretas. Dalam kasus ini, HTTP POST harus digunakan.[7]

Saya hanya bisa menyarankan kepada SELURUH tim untuk mempertimbangkan lebih aman menggunakan protokol HTTP untuk menghindari membuat konsumen perjuangan dengan non-aman "praktek yang baik".

Komentar (1)

Di SISA, masing-masing HTTP verba memiliki tempat dan makna.

Misalnya,

  • DAPATKAN adalah untuk mendapatkan 'sumber daya(s)' yang menunjuk pada alamat URL.

  • POST ini adalah untuk instruktur backend untuk 'buat' sumber daya dari 'jenis' menunjuk ke dalam URL. Anda dapat melengkapi POST operasi dengan parameter atau data tambahan pada tubuh POST panggilan.

Dalam kasus anda, karena anda tertarik 'mendapatkan' info menggunakan query, sehingga harus MENDAPATKAN operasi bukan POST operasi.

Ini wiki dapat membantu untuk lebih memperjelas hal-hal.

Harap ini membantu!

Komentar (0)

POSTING ini berlaku untuk menggunakan bukan DAPATKAN jika anda memiliki alasan tertentu untuk melakukannya dan proses itu dengan benar. Saya mengerti itu's tidak secara khusus RESTy, tetapi jika anda memiliki banyak ruang dan ampersands dan garis miring dan sebagainya dalam data anda [misalnya model produk seperti Amazon] kemudian mencoba untuk encode dan decode ini dapat menjadi masalah lebih dari itu's bernilai bukan hanya pra-jsonifying itu. Pastikan meskipun bahwa anda mengembalikan kode respon yang tepat dan banyak komentar apa yang anda're lakukan karena itu's tidak khas use case dari POS.

Komentar (0)