API consistentie HTTP commando bij geo-query

Overig
#1

Indien bij ‘geografisch zoeken’ een HTTP body meegegeven moet worden, zie ik dat bij BRK en BRT er voor gekozen is om HTTP commando PUT te gebruiken, terwijl bij BAG HTTP commando POST wordt gebruikt.

Dit probleem is op het internet natuurlijk al tot in den treure besproken (meest logisch blijft toch een GET met een body). Een PUT commando om een query te doen (zonder daadwerkelijk een resource te wijzigen) vind ik vreemd. Een POST commando is hier beter te verantwoorden in de zin van HTTP semantiek. Zou het dus niet beter zijn om voor dit doel overal consistent het HTTP POST commando te hanteren?

#2

@jasperroes graag jouw reactie naar @geertdoornbos . Alvast bedankt!

#3

@geertdoornbos Klopt! Dit komt doordat de BAG API final is en de BRT API nog van de bèta versie dateert. Binnenkort komt BRT API v2 uit en daarin is dit een POST.

Overigens is een GET met een body geen optie want dit is geen valide HTTP en wordt derhalve ook niet door alle clients ondersteund.

@Rob bij vragen over de API’s mag je voortaan mij taggen :wink:

#4

Dat verklaart het, merci :slight_smile:

Of het geen valide HTTP is, heb ik niet uit de specs opmaken. Hoewel ik het technisch heel logisch zou vinden, het is in ieder geval semantisch onjuist (en dus niet overal ondersteund) :

A payload within a GET request message has no defined semantics;
sending a payload body on a GET request might cause some existing
implementations to reject the request.
https://tools.ietf.org/html/rfc7231#section-4.3.1

Eigenlijk jammer dat omdat iets semantisch onjuist is, het protocoltechnisch niet wordt ondersteund. Lazy devs :innocent:

#5

Jep. En nu hebben we met POST op een collectie nog een mooie uitweg, maar als er ook schrijfacties ondersteund moeten worden is deze combinatie al gereserveerd. In toekomstige API’s zal de geo query dan waarschijnlijk ook een eigen endpoint krijgen (bijvoorbeeld /panden/_geo of iets dergelijks).