HTTP GET en vereiste input variabelen

[Emiel1984]

Goedemiddag,

Om gegevens van een server op te vragen ben ik momenteel genoodzaakt om variabelen in de URL mee te geven.

voorbeeld:

code:

https://www.randomlocation.com/server_services/server_service1.asmx/GetFiles?&Offset=0&size=10

Aangezien de API die ik hiervoor gebruik momenteel wordt ge-update om JSON geformatteerde data input en outputs te ondersteunen ben ik tegen een vraagstuk aangelopen tijdens het reviewen.

Bij de (HTTP) GET aanvraag zijn nog steeds de variabelen in de URL vereist om de juiste gegevens van de server te krijgen. Echter wil ik deze heel graag uit de URL zien verdwijnen. Ik zie dit liever in het JSON formaat om zodoende maar een type formaat te hoeven ondersteun in de software op de clients.

Maar bij een GET heb je helaas niet de optie op variabelen mee te geven als 'content'.
Omdat we de REST guideline willen respecteren, willen we voor een het opvragen van data ook liever geen HTTP Post uitvoeren.

Omdat ik denk dat vaker mensen tegen dit probleem zijn aangelopen hoop ik dat iemand van jullie een mij kan vertellen hoe jullie hier mee zijn omgegaan. Het belangrijkste is dat we niet willen afwijken van de REST guidelines.

Ik hoop dat ik niet te veeleisend ben .

[dev10]

Bij de (HTTP) GET aanvraag zijn nog steeds de variabelen in de URL vereist om de juiste gegevens van de server te krijgen. Echter wil ik deze heel graag uit de URL zien verdwijnen.

Waarom zou je dit uit de URL willen halen? Daar zijn deze parameters juist voor bedoeld. Voor de PUT, POST en DELETE requests, kun je gewoon met een post body werken en aan de hand van de Content-Type de gegevens op de juiste manier verwerken.

Ik zie dit liever in het JSON formaat om zodoende maar een type formaat te hoeven ondersteun in de software op de clients.

En waarom precies? De request naar de API doe je normaal gesproken met een HTTP library. Een voorbeeldje in PHP:

PHP:

$client = new GuzzleHttp\Client();
$res = $client->request('GET', 'https://www.randomlocation.com/server_services/server_service1.asmx/GetFiles', [
    'query' => ['Offset' => 10, 'size' => 0]
]);

Ik voer hier een array met parameters aan Guzzle, en die zorgt er vervolgens voor dat de juiste URL opgebouwd wordt. Een kind kan de was doen.

[Cartman!]

Emiel1984 schreef op dinsdag 23 augustus 2016 @ 17:17:
Het belangrijkste is dat we niet willen afwijken van de REST guidelines.

Welke REST guidelines doel jij op dan?

[Juup]

Je kunt prima JSON data in een GET request duwen:

code:

http://server.com/path?{"offset":0,"size":10}

Het is even wennen, zeker als de browser alle curlies ge-escaped in de adresbalk toont maar het werkt prima.

[Ventieldopje]

Emiel1984 schreef op dinsdag 23 augustus 2016 @ 17:17:
Het belangrijkste is dat we niet willen afwijken van de REST guidelines.

Ehh? Juist. JSON is niet bedoeld als vervanging voor GET request parameters (over het afwijken van standaarden trouwens...). JSON wordt gebruikt (naast bijv. XML) als response waarde en bij POST requests als payload.

Ga niet moeilijk lopen doen en gebruik gewoon GET parameters ,stukken makkelijker

[Emiel1984]

Bedankt voor de snelle reacties. Even voor de duidelijkheid, de payload is wat momenteel JSON formatted wordt.

Het is me nu duidelijk geworden dat mijn vraag wat vreemd was. De methode van hoe parameters meegegeven worden is al zoals vereist is. Dus bedankt voor het verhelderen hiervan.

Edit:
Voor de mensen die in dit topic komen met dezelfde vraag..

http://www.w3.org/2001/tag/doc/whenToUseGet.html

By convention, when GET method is used, all information required to identify the resource is encoded in the URI. There is no convention in HTTP/1.1 for a safe interaction (e.g., retrieval) where the client supplies data to the server in an HTTP entity body rather than in the query part of a URI.

[ Voor 42% gewijzigd door Emiel1984 op 23-08-2016 21:27 . Reden: bron vermelding voor meer info. ]

[merauder]

Of je data in een URI moet duwen of niet hangt ook van de gevoeligheid af. Een offset / limit is prima om 'publiek' te hebben, zodat je bijvoorbeeld ook gewoon custom feeds kan implementeren. Een username of password via GET transporteren is in principe geen goed idee, net als content overigens. Het is heel makkelijk om dan een URL te bouwen als 'HTTP://belastingdienst.nl?content=stuurgeldnaarmijnpriverekeningmetrekeningnummer12344' .

Wil je per se wachtwoorden over $_GET sturen, dan is een JWT ook wel een te overwegen optie.

[ZeroXT]

Je kan eventueel ook JSON webtokens overwegen.

[gron74]

Je kunt prima data posten met parameters in de URL. Misschien niet goed in de ogen van REST, maar nood breekt wet Ik heb het in de praktijk al gebruikt. Parameter in de URL die een functie aangeeft en data in de POST body.

[simon]

Waarom mag je geen params in een GET url bij een rest request gebruiken? Als jij een lijst met resources ophaalt doe je een get request, met params. Die kun je niet in je url kwijt.