Żądanie Curl GET z parametrem JSON

124

Próbuję wysłać żądanie „GET” do zdalnego interfejsu API REST z wiersza polecenia za pośrednictwem cURL w następujący sposób:

curl -X GET -H "Content-type: application/json" -H "Accept: application/json"  "http://server:5050/a/c/getName/{"param0":"pradeep"}"

Ale nie zwraca żadnego wyniku. Próbowałem pingować adres URL bezpośrednio z przeglądarki, jestem w stanie uzyskać odpowiedź, nie rozumiem, co jest nie tak z poleceniem.

Zasadniczo chcę ustawić żądanie „GET” do zdalnej usługi REST, która dostarcza mi dane JSON jako odpowiedź za pośrednictwem curl. Czy ktoś może mnie poprowadzić, jaki błąd robię? Wypróbowałem różne posty, ale wszystkie mówią o żądaniach POST, a nie o GET.

json rest curl

— Pradeep Simha
źródło

jakie błędy są publikowane po stronie twojego serwera?

— Straszny wombat

Brak błędów, po stronie serwera jest wykonywany pomyślnie. Ale od strony zawinięcia nie wyświetla żadnych danych. Po prostu pinguje po kilku sekundach, po prostu wyświetla się pusty bez danych.

— Pradeep Simha

czy możesz spróbować z curl -i -H "Accept: application / json" " server: 5050 / a / c / getName {" param0 ":" pradeep "}" (opcja -i zamiast x).

— Harshal Bulsara

139

To powinno działać:

  curl -i -H "Accept: application/json" 'server:5050/a/c/getName{"param0":"pradeep"}'

użyj opcji -i zamiast x.

— Harshal Bulsara
źródło

4

może inny cytat? "server: 5050 / a / c / getName {'param0': 'pradeep'}"

— AB,

Naprawdę powinno być albo 'server:5050/a/c/getName{"param0":"pradeep"}'albo "server:5050/a/c/getName{\"param0\":\"pradeep\"}".

— Benjamin W.

16

Jeśli chcesz wysłać swoje dane do ciała, musisz zrobić POSTlub PUTzamiast GET.

U mnie wygląda na to, że próbujesz wysłać zapytanie z parametrami uri , które nie są powiązane GET, możesz również ustawić te parametryPOST , PUTi tak dalej.

Zapytanie jest częścią opcjonalną, oddzieloną znakiem zapytania („?”), Która zawiera dodatkowe informacje identyfikacyjne, które nie mają charakteru hierarchicznego. Składnia ciągu zapytania nie jest zdefiniowana ogólnie, ale zwykle jest zorganizowana jako sekwencja par =, z parami oddzielonymi średnikiem lub ampersandem.

Na przykład:

curl http://server:5050/a/c/getName?param0=foo&param1=bar

— Martin Seeler
źródło

7

Każda wiadomość żądania HTTP może zawierać treść wiadomości. Nigdy nie jest przydatna dla GET ze względu na semantykę GET - treść żądania, jeśli taka istnieje, nie powinna zmieniać odpowiedzi.

— Jarek Przygódzki

12

Jeśli naprawdę chcesz przesłać żądanie GET z JSON w treści (powiedzmy w przypadku żądania XHR i wiesz, że serwer obsługuje przetwarzanie treści w żądaniach GET), możesz:

curl -X GET \
  -H "Content-type: application/json" \
  -H "Accept: application/json" \
  -d '{"param0":"pradeep"}' \
  "http://server:5050/a/c/getName"

Większość nowoczesnych serwerów WWW akceptuje tego typu żądania.

— Steven Soroka
źródło

To nie daje zamierzonego rezultatu. Użycie httpbin.org/get do debugowania daje:

{   "args": {},   "headers": {     "Accept": "application/json",     "Content-Length": "20",     "Content-Type": "application/json",     "Host": "httpbin.org",     "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:57.0) Gecko/20100101 Firefox/57.0"   },   "origin": "27.94.235.50, 27.94.235.50",   "url": "https://httpbin.org/get" }

Nic nie jest odbierane. Musisz użyć ciągu zapytania, takiego jakcurl -X GET https://httpbin.org/get?data=%7B%22param0%22%3A%22pradeep%22%7D

— Jacques

Zależy to od tego, czy serwer WWW sprawdza treść żądań GET, co, przyznaję, nie jest całkowicie standardowym zachowaniem. Lepiej będzie, jeśli użyjesz parametrów zapytania adresu URL, tak jak mówisz. Jednym z problemów związanych z używaniem treści w żądaniu pobierania jest to, że przeglądarka nie może odtworzyć żądania, nawigując po historii przeglądarki, chociaż prawdopodobnie jest to w porządku w przypadku żądań XHR.

— Steven Soroka

Alternatywnie, co można zrobić, jeśli ma się wystarczającą kontrolę po stronie serwera, to dodać specjalną właściwość do danych json, jak "metoda": "get", wysłać ładunek w żądaniu pocztowym i poprosić o interpretację kodu na serwerze jako prośba o uzyskanie.

— Jacques

@Jacques, oczywiście, ale jeśli masz kontrolę nad serwerem, równie łatwo możesz sprawić, by serwer odczytywał treści żądań GET. Wracając do pierwotnego pytania, myślę, że cała ta styczna jest trochę nie na temat. Czytając ponownie pytanie, nie sądzę, aby OP miał dostęp do zmiany serwera.

— Steven Soroka

tak to prawda. Jeśli kontrolujesz serwer. Mój komentarz został pobudzony przez następujące oświadczenie, które, jak powiedziałem, nie przyniesie zamierzonego rezultatu: „Większość współczesnych serwerów WWW akceptuje tego typu żądania”. W rzeczywistości zaakceptowaliby opisaną przez Ciebie prośbę, ale żądanie nie przyniosłoby zamierzonego rezultatu. Możesz też zrewidować stwierdzenie w ten sposób: „Większość nowoczesnych serwerów internetowych akceptuje tego typu żądania, zakładając, że masz bezpośrednią kontrolę po stronie serwera, ale jest to niestandardowe”

— Jacques

8

GET przyjmuje pary nazwa-wartość.

Spróbuj czegoś takiego:

curl http://server:5050/a/c/getName/?param1=pradeep

lub

curl http://server:5050/a/c/getName?param1=pradeep

przy okazji zwykły REST powinien wyglądać mniej więcej tak

curl http://server:5050/a/c/getName/pradeep Jeśli pobiera JSON w GET URL, nie jest to standardowy sposób.

— user2877889
źródło

4

W przypadku usług chronionych nazwą użytkownika i hasłem użyj następującego

curl -u admin:password -X GET http://172.16.2.125:9200 -d '{"sort":[{"lastUpdateTime":{"order":"desc"}}]}'

— Sandeep KV
źródło

curl -X POST -H "Content-type: application / json" -d '{"stuff": "things"}' http: // ...

— keithpjolley

Popraw mnie, jeśli się mylę, ale użycie opcji -d na żądaniu curl (i nie określanie metody) spowoduje, że żądanie będzie POST.

— Gokigooooks

3

Próbować

curl -G ...

zamiast

curl -X GET ...

Zwykle nie potrzebujesz tej opcji. Wszystkie rodzaje żądań GET, HEAD, POST i PUT są raczej wywoływane przy użyciu dedykowanych opcji wiersza poleceń.

Ta opcja zmienia tylko rzeczywiste słowo użyte w żądaniu HTTP, nie zmienia zachowania curl. Na przykład, jeśli chcesz wykonać prawidłowe żądanie HEAD, użycie -X HEAD nie wystarczy. Musisz użyć opcji -I, --head.

— smci
źródło

1

Żadne z powyższych rozwiązań nie zadziałało u mnie z jakiegoś powodu. Oto moje rozwiązanie. To całkiem proste.

curl -X GET API_ENDPOINT -H 'Content-Type: application / json' -d ' JSON_DATA '

API_ENDPOINT to punkt końcowy twojego API, np .: http://127.0.0.1:80/api

-H zostało użyte do dodania zawartości nagłówka.

JSON_DATA to treść Twojego żądania, może to być coś w rodzaju :: {"data_key": "value"}. '' otaczające JSON_DATA są ważne.

Wszystko po -d to dane, które musisz wysłać w żądaniu GET

— bhatman
źródło