İstək bədəni ilə HTTP GET

Ərizə üçün yeni RESTful web xidmətini hazırlayıram.

GET'i müəyyən obyektlərdə yerinə yetirərkən, müştərilər obyektin məzmununu tələb edə bilərlər. Bəzi parametrləri əlavə etmək istəyirsinizsə (məsələn, siyahı sıralayın), bu parametrləri sorğu sətrinə əlavə edə bilərsiniz.

Alternativ olaraq, insanların istək orqanında bu parametrləri göstərmələrini istərdim. HTTP / 1.1 bu açıqca qadağan etmir. Bu onlara mürəkkəb XML sorgularının tərifini asanlaşdıra biləcək daha ətraflı məlumat vermək üçün imkan verir.

Mənim suallarım:

  • Bu yaxşı bir fikirdir?
  • HTTP müştərilərinin GET tələbində istək orqanlarını istifadə etməsi problemləri varmı?

http://tools.ietf.org/html/rfc2616

1571
10 июня '09 в 23:47 2009-06-10 23:47 İyun ayının 10-da saat 23: 00-da saat 23: 47-da olacaq
@ 18 cavab

Roy Fielding'in bədənə bir GET tələbi ilə daxil edilməsi mövzusunda şərh .

Bəli Başqa sözlə, hər hansı bir HTTP sorğu mesajı bir mesaj orqanı ola bilər və bu səbəbdən mesajları nəzərə alaraq təhlil etməlidir. Buna baxmayaraq, GET üçün server semantikası məhduddur, bədənin varsa, istək üçün semantik bir mənası yoxdur. Ayrıştırma tələbləri metodun semantikası üçün tələblərdən ayrılır.

Bəli, bədəni GET ilə göndərə bilərsiniz və heç bir zaman faydalı deyil.

Bu, spesifikasiya bölündükdən sonra yenidən işə düşəcək HTTP / 1.1 qatlı strukturunun bir hissəsidir.

Roy

Bəli, istək orqanını GET istifadə edərək göndərə bilərsiniz, ancaq bunun heç bir mənası yoxdur. Əgər serverdə təhlil edərkən və onun məzmununa görə cavabı dəyişdirərək dəyər verərsənsə, bu təklifi HTTP / 1.1 spesifikasiyasında, 4.3 bölməsində görmürsən :

[...] Əgər sorğu metodu obyektin cismi üçün xüsusi semantikləri əhatə etmirsə, sorğu işləyərkən mesaj orqanına diqqət edilməməlidir .

HTTP / 1.1 spesifikasiyasında GET metodunun təsviri , bölmə 9.3 :

GET metodu, İstehlak-İstehlakçı Qrupu tərəfindən müəyyən edilən hər hansı məlumatın çıxarılması deməkdir ([...].

sorğu orqanının GET tələbində resurs identifikasiyasının bir hissəsi deyil, yalnız tələb URI olduğunu bildirir.

"HTTP / 1.1 spec" adlanan RFC2616 yeniləməsi artıq köhnəlmişdir. 2014-cü ildə RFC 7230-7237 ilə əvəz edilmişdir. Bir sorğu işləyərkən "mesaj orqanına diqqət edilməməlidir" ifadəsi çıxarıldı. İndi o, sadəcə bir mesaj tərtibatının istifadəsi metodun semantikasından asılı deyildir, hətta metod mesaj orqanı üçün istifadəni müəyyən etmir. " İkincisi: "GET üsulu, İstək-URI ilə müəyyənləşdirilmiş hər hansı məlumatın alınması deməkdir" - şərhdən silinmişdir

1313
11 июня '09 в 23:27 2009-06-11 23:27 Cavab Paul Morgan tərəfindən 11 iyun 'da 23:27' də verildi. 2009-06-11 23:27

Bunu edə biləcəyiniz müddətcə, HTTP spesifikasiyası tərəfindən açıq şəkildə qadağan edilmədiyindən, insanların bir şeyin bu şəkildə işləməyini gözləməyəcəyi üçün sadəcə qaçmaq istəmərəm. HTTP sorğu zəncirində bir çox mərhələ var və onlar "əsasən" HTTP spesifikasiyasına uyğun olsa da, əmin olduğunuz bir şey, ənənəvi olaraq veb brauzerlərdən istifadə edəcəkdir. (Şəffaf proxies, sürətləndiricilər, A / V alətləri və s. Kimi şeyləri düşünürəm)

Bu ruh, "qəbul etdiyiniz şeylərdə liberal və göndərdiyiniz mühafizəkar" mövzusunda sərtlik prinsipidir. Mən dəqiqləşdirmənin sərhədlərini asanlıqla əsaslandırmaq istəyirəm.

border=0

Ancaq yaxşı bir səbəb varsa, bunun üçün get.

243
10 июня '09 в 23:53 2009-06-10 23:53 cavab 10 iyun 'da saat 23:53' da 09.06.2009 23:53 tarixində açıqlanacaq

Önbelleğe istifadə etməyə çalışarsanız, yəqin ki, problemlərlə qarşılaşacaqsınız. Proxy, parametrlərin cavabını təsir etdiyini görmək üçün GET bədəninə baxmağa gedir.

123
11 июня '09 в 0:10 2009-06-11 00:10 Cavab Darrel Millerə 11 iyun '09 'da 0:10 2009-06-11 00:10 verilir

restclient,də REST paneli bunu dəstəkləmir.

HTTP spesifikasiyası 4.3 bölməsində deyir

Sorğu metodunun dəqiqləşdirilməsi (Bölmə 5.1.1) obyektin orqanına istəklərə göndərilməsinə imkan vermirsə, mesaj orqanı tələbə daxil edilməməlidir.

Bölmə 5.1.1 bizi müxtəlif metodlar üçün 9.x bölməsinə yönəldir. Onların heç biri mesaj orqanının daxil edilməsini açıq şəkildə qadağan edir. Ancaq ...

Bölmə 5.2-də deyilir

Internet sorğusu ilə müəyyən edilmiş dəqiq resurs, İstehlak-İstehlakçı Qrupu və Ana səhifə başlığı ilə araşdırılır.

Bölmə 9.3-də deyilir

GET metodu, İstek-URI ilə müəyyən edilmiş hər hansı bir məlumatın (obyekt şəklində) alınmasını nəzərdə tutur.

Birlikdə biz bir GET tələbi işləyərkən serverin İstək-URI və Host üstbilgi sahələrindən başqa heç bir şey yoxlamasına ehtiyac olmadığını düşünürük.

Beləliklə, HTTP spesifikasiyası, mesaj gövdəsini GET ilə göndərməyinizi maneə törədir, amma bütün serverlər tərəfindən dəstəklənməsə, məni təəccübləndirməyəcək kifayət qədər qeyri-müəyyənlik var.

62
27 марта '13 в 13:41 2013-03-27 13:41 Cavab Dave Durbin tərəfindən 27 Mart '13 'də saat 13:41' də verilir. 2013-03-27 13:41

Elasticearch, GET tələblərini bədən ilə qəbul edir. Bu, seçilmiş seçimdir: http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/common-options.html#_request_body_in_query_string

Bəzi müştəri kitabxanaları (məsələn, Ruby sürücüsü), dizayn rejimində stdout üçün cry komutunu yaza və bu sözdizmin geniş şəkildə istifadə edə bilər.

39
03 дек. Cavab cümə axşamı 03 dekabr verilir . 2013-12-03 14:15 '13 'da 14:15' de 2013-12-03 14:15

Nə əldə etməyə çalışdığınız, çox daha geniş yayılmış üsulla uzun müddətdir və GET-in istifadə etdiyi yükün istifadəsinə güvənməyən bir şeydir.

Sadəcə, öz xüsusi axtarış növünü yaratmaq və ya daha RESTful olmaq istəyirsinizsə, OpenSearch kimi bir şey və serverın əmri verdiyi bir URI üçün bir POST sorğu istifadə edin, bir axtarış / demək. Server bundan sonra axtarış nəticəsini yarada və ya son URI qura və 303 istifadə edərək yenidən yönləndirə bilər.

Bu, ənənəvi PRG metoduna riayət etmək üstünlüyünə malikdir, pul vasitəçilərinə nəticələrin önünə keçməsinə kömək edir və s.

Bununla belə, URI hər halda ASCII olmayan bir şey, eləcə də ərizə / x-www-form-urlencoded və multipart / form-data üçün şifrələnir. ReSTlu skriptləri dəstəkləmək niyyətindəsinizsə, bu başqa bir xüsusi json formatı yaratmaq əvəzinə istifadə etməyi məsləhət görürəm.

26
11 июня '09 в 1:47 2009-06-11 01:47 Cavab SerialSeb 11 iyun '09 saat 01:47 'da verilir. 2009-06-11 01:47

Hansı server bunu görməyəcək? - fijiaaron 30 Avqust '12 saat 21:27

Google , məsələn, onu görməməzdən daha pis edir, bu bir səhv hesab edəcək!

Sadə bir netcat ilə özünüzü sınayın:

 $ netcat www.google.com 80 GET / HTTP/1.1 Host: www.google.com Content-length: 6 1234 

(1234 məzmunu CR-LF tərəfindən izlənilir, buna görə də bu, yalnız 6 baytdır)

və əldə edəcəksiniz:

 HTTP/1.1 400 Bad Request Server: GFE/2.0 (....) Error 400 (Bad Request) 400. That's an error. Your client has issued a malformed or illegal request. That's all we know. 

AkamaiGhost tərəfindən xidmət edilən Bing, Apple, və s.

Buna görə də, GET istəklərini bədən mahiyyəti ilə istifadə etməyi məsləhət görmürəm.

22
30 июня '13 в 0:26 2013-06-30 00:26 Cavab, user941239 30 iyun 2013- cü ildə 0:26 2013-06-30 00:26 tərəfindən verilir

Bədən ilə bir GET göndərə bilərsiniz və ya bir POST göndərə və RESTish dindarlığından imtina edə bilərsiniz (bu 5 il əvvəl bu imanın yalnız bir üzvü var idi - şərhləri yuxarıda bağlıdır).

Həmçinin, heç bir böyük qərar qəbul edilmir, lakin bir GET orqanının göndərilməsi bəzi müştərilərin - və bəzi serverlərin problemlərinin qarşısını ala bilər.

Bir POST yerinə yetirmək, bəzi RESTish çərçivələrinə mane ola bilər.

Julian Reschke yuxarıda yuxarıda "SEARCH" kimi qeyri-standart bir HTTP başlığını istifadə edərək təklif etdi ki, bu da zərif bir həll ola bilər.

Yəqin ki, ən məhsuldar, yuxarıda qeyd olunan hər birini tamamlaya bilməyən və edə bilməyən müştərilərin köçürülməsi olacaq.

Bədəni (bildiyim) bir GET göndərə bilməyən müştərilər:

  • XmlHTT Tərsəb Fiddler

Bədən ilə GET göndərə bilən müştərilər:

  • Ən çox brauzerlər

Bədəni GET'den ala biləcək serverlər və kitabxanalar:

  • Apache
  • Php

Bədəni GET'den kəsən serverlər (və proksi):

21
31 авг. Cavab 31 avqustda fijiaaron verilir 2012-08-31 00:41 '12 at 0:41 2012-08-31 00:41

RFC 2616, Bölmə 4.3 , "Mesaj Bədəni":

Server hər hansı bir istək üzrə mesaj orqanını oxumalı və göndərməlidir; sorğu metodu, mövzu gövdəsi üçün xüsusi semantikləri içermiyorsa, mesaj gövdesi isteği işlenirken göz ardı edilmemelidir.

Beləliklə, serverlər həmişə şəbəkədən istənilən istək orqanını oxumalıdırlar (Content-Length yoxlayın və ya parçalanmış bədəni oxumaq və s.). Bundan əlavə, vekiller, aldıqları hər hansı bir istək orqanını yönlendirmelidir. Sonra RFC bu metod üçün bədən semantikasını təyin edərsə, server cavab verməklə, həqiqətən, istək orqanını istifadə edə bilər. Lakin, RFC bədən üçün semantik müəyyən etmirsə, server onu görməməlidir.

Bu, Fielding-dən yuxarıdakı sitata cavab verir.

Bölmə 9.3 , "GET", GET metodunun semantikasını təsvir edir və tələbin cismini qeyd etmir. Buna görə, server, GET tələbində aldığınız hər hansı bir istək orqanını görməməlidir.

16
07 марта '14 в 0:44 2014-03-07 00:44 Cavab izrik 07 mart '14 saat 0:44 'da verilir 2014-03-07 00:44

Bu məsələni IETF HTTP iş qrupunda soruşdum. Roy Fielding'in şərhində (1998-ci ildə http / 1.1 yazısı) bu idi

"... həyata keçirildiyi təqdirdə, bu orqanın analizindən və atılmasından başqa heç bir şey etmək üçün tətbiq olunacaq"

RFC 7213 (HTTPbis) deyir:

"GET tələb mesajında ​​yükün xüsusi semantikası yoxdur";

İndi aydın görünür ki, niyyət GET tələbinin orqanlarında semantik məna qadağandır, yəni istək orqanının nəticəyə təsir etmək üçün istifadə edilə bilməməsi deməkdir.

Bədəni GET-də daxil etdikdə, mütləq müxtəlif yollarla tələbinizi pozan proxy serverləri var.

Qısacası, bunu etməyin.

13
28 июля '16 в 4:06 2016-07-28 04:06 cavab Adrien 28 iyul '16 'da 4:06 2016-07-28 04:06' də verilir

Bir web tətbiqi üçün həqiqətən Cachable JSON / XML orqanı göndərmək istəyirsinizsə, məlumatlarınızı yerləşdirmək üçün yalnız həssas bir yer RFC4648 istifadə kodlanmış sorgu simvoludur: Base 64 URL və fayl adlarının təhlükəsiz əlifbası ilə kodlaşdırma. Əlbəttə, urlencode JSON-ı təyin edə və URL parametresinin dəyərinə qoyub, lakin Base64 daha kiçik nəticə verir. URL'nin ölçüsündə məhdudiyyətlər olduğunu unutmayın , müxtəlif brauzerlərdə URL'nin maksimum uzunluğu nədir? .

Base64 padding = simvolu URL parametresinin dəyəri üçün pis ola bilər, ancaq yanlış görünür - bu mübahisəyə baxın: http://mail.python.org/pipermail/python-bugs-list/2007- Fevral / 037195.html . Kodlanmış simli boş bir dəyər ilə param açarı olaraq şərh ediləcəyi üçün, kodun məlumatlarını param adı olmadan verməməlisiniz. Kimi bir şey istifadə edirəm ?_b64=<encodeddata> .

7
18 февр. 18 fevralda gertas tərəfindən verilən cavab . 2013-02-18 16:43 '13 at 16:43 2013-02-18 16:43

Protokolun OOP-i dəstəkləmədiyi və REST-in alınması üsulu sübutdur, çünki REST-in pozulduğu məndən üz döndərirəm. Bir həll olaraq, DTO-nun JSON-ə seriyalaşdırılması və sonra bir sorğu sətri yarada bilərsiniz. Sunucu tarafında, DTO'daki sorgu dizgesini serbestleştirebilirsiniz.

Bir göz atın:

Mesaj əsaslı yanaşma, Get metodunun məhdudiyyətini həll etməyə kömək edə bilər. Hər hansı bir DTO-nu istək orqanında göndərə bilərsiniz.

Nelibur veb xidmətinin strukturu istifadə edə biləcəyiniz funksiyaları təmin edir

 var client = new JsonServiceClient(Settings.Default.ServiceAddress); var request = new GetClientRequest { Id = new Guid("2217239b0e-b35b-4d32-95c7-5db43e2bd573") }; var response = client.Get<GetClientRequest, ClientResponse>(request); as you can see, the GetClientRequest was encoded to the following query string http://localhost/clients/GetWithResponse?type=GetClientRequest> 
5
10 февр. GSerjo tərəfindən verilmiş cavab 10 fevral. 2014-02-10 02:04 '14 at 2:04 2014-02-10 02:04

XMLHttpRequest'e görə, bu yanlışdır. Standartdan :

4.5.6 send() metodu

 client . send([ body = null]) 

Bir sorğu başlatır. İstənilən arqument tələbin orqanını təmin edir. İstək üsulu GET və ya HEAD GET arqument nəzərə alınmır.

InvalidStateError istisna InvalidStateError dövlət InvalidStateError və ya send() bayrağı InvalidStateError .

send( body ) üsulu bu addımları yerinə yetirməlidir:

  1. Dövlət açıq deyilsə, InvalidStateError istisna edir.
  2. send() bayrağı quraşdırılmışdırsa, InvalidStateError istisna edir.
  3. İstək üsulu GET və ya HEAD , bədəni null olaraq təyin edin.
  4. Cəsəd boşsa, növbəti addıma keçin.

GET tələbi bir çox məzmun tələb edə bilər, çünki mən bu şəkildə olmalıdır düşünməmişəm baxmayaraq.

Belə ki, brauzerinizin XMLHttpRequest istifadə etsəniz, çox güman ki, işləməyəcəkdir.

5
04 мая '16 в 23:07 2016-05-04 23:07 Cavab Rafael Sales tərəfindən mayın 04-dən 16-dək 23:07 2016-05-04 23:07 tarixində verilir

Nə uyğun olmayan baz64 kodlanmış başlıqlar haqqında? "SOMETHINGAPP Başlıqları: sdfSD45fdg45 / SOS"

Uzunluq hm məhdudiyyətləri. Değerleri ayırt etmək üçün POST işini edə bilərsinizmi? Sıralama kimi sadə parametrlərə ehtiyacınız varsa, bunun niyə bir problem olacağını anlamıram. Mən sizə narahat olduğunuza əminəm.

4
16 февр. cavab caz 16 feb . 2011-02-16 00:34 '11 at 0:34 2011-02-16 00:34

Məsələn, Curl, Apache və PHP ilə işləyir.

PHP faylı:

 <?php echo $_SERVER['REQUEST_METHOD'] . PHP_EOL; echo file_get_contents('php://input') . PHP_EOL; 

Konsol əmri:

 $ curl -X GET -H "Content-Type: application/json" -d '{"the": "body"}' 'http://localhost/test/get.php' 

Nəticə:

 GET {"the": "body"} 
4
21 нояб. cavab mnv 21 nov verir. 2015-11-21 01:16 '15 'də 1:16' de 2015-11-21 01:16

IMHO, sadəcə JSON encodeURIComponent (yəni, encodeURIComponent ) URL encodeURIComponent göndərə bilərsiniz, buna görə də HTTP spesifikasiyalarını pozmur və server üçün JSON almazsınız.

4
26 февр. Cavab 26 fevral etirazına verilib . 2013-02-26 22:04 '13 at 10:04 PM 2013-02-26 22:04

Mən bunu məsləhət görmürəm, bu standart təcrübələrə zidd və bunun əvəzinə təklif vermir. Bədən məzmununu parametrlər deyil, qənaət etmək istəyirəm.

3
10 июня '09 в 23:56 2009-06-10 23:56 cavab 10 iyun 2009 -cu il saat 23:56 'da buludhead tərəfindən verilmişdir. 2009-06-10 23:56

Google, IBM, Microsoft və apigee, X-HTTP-Method-Override: GET kimi həqiqətən gözlənilən metodu göstərmək üçün bir başlıq istifadə görünür.
Yuxarıdakı bloga görə, bu POST formasında PUT olaraq daxil edilir.
Hesab edirəm ki, bu həll bu problemdə istifadə edilə bilər.

Başqa sözlə, POST X-HTTP-Override metodu ilə düşünürəm: GET başlığı ən yaxşı həlldir.

0
26 окт. cavab verildi tabata Oct 26 2016-10-26 05:25 '16 saat 05:25 'də 2016-10-26 05:25

bağlı digər suallar və ya bir sual