Ruimtelijke plannen opvragen API - errors 500 en 504

Datasets Ruimtelijke Plannen
,
1

Bij het gebruik van de ‘Ruimtelijke plannen opvragen’ REST API krijg ik regelmatig foutcodes. Bij de zoekfunctie verschillende resultaten per poging. Soms werkt deze, maar dan pas na 30 seconden. In andere gevallen krijg ik een 500 internal server error of een 504 Gateway Time-Out zoals hier:

curl -X POST
https://data.informatiehuisruimte.nl/api/ruimtelijke-plannen/v2/plannen/_zoek
-H ‘Cache-Control: no-cache’
-H ‘Content-Type: application/json’
-H ‘Postman-Token: 27c1daf1-da6e-d619-54db-d7e8b06c6fc9’
-H ‘x-api-key:{API KEY}’
-d ‘{"_geo":{“contains”:{“type”:“Point”,“coordinates”:[5.097726930982758,51.80864604295673]}}}’

Geeft:

504 Gateway Time-out

504 Gateway Time-out

nginx

Een voorbeeld van de internal server error is deze:

curl -X POST
‘https://data.informatiehuisruimte.nl/api/ruimtelijke-plannen/v2/plannen/_zoek?page=2’
-H ‘Cache-Control: no-cache’
-H ‘Content-Type: application/x-www-form-urlencoded’
-H ‘Postman-Token: d52e101a-8150-bc86-5681-79ebabe70b90’
-H 'x-api-key: ‘x-api-key:{API KEY}’ ’

Produce this:
{
“title”: “Internal Server Error”,
“status”: 500,
“detail”: “An error occured from which the server was unable to recover.Please contact the system administrator with the following details: ‘77b0696f’”
}

Ervaren anderen dezelfde problemen, en is hier een oplossing voor?

2

Wij zijn op de hoogte van deze problemen met de 504’s en zijn druk bezig om deze te verhelpen. Dit is echter een complexe operatie omdat de 504 voortkomen uit queries op de database die langer dan een minuut duren. We zijn nu een aantal aanpassingen aan het uitwerken en implementeren die het aantal 504’s flink naar beneden zal brengen omdat de achterliggende queries op de database sneller zijn. Deze wijzigingen verwachten we aan het einde van dit kwartaal uit te rollen in een nieuwe versie (v3) van de API ivm niet-backwards compatible changes. De volledige oplossing laat echter nog wat langer op zich wachten omdat we daarvoor een nieuwe database moeten realiseren.

De 500 error die je als voorbeeld geeft komt waarschijnlijk omdat je een content-type opgeeft dat de API niet ondersteunt. Zou je dezelfde query eens willen proberen met content-type ‘application/json’?

2 likes
3

Bedankt voor je antwoord en fijn dat hieraan gewerkt wordt!

Over de 500 melding: dit gebeurt ook als ik application/json kies als content-type.

Je kunt deze fout reproduceren door (in Postman) naar plannen te gaan:
https://data.informatiehuisruimte.nl/api/ruimtelijke-plannen/v2/plannen

en vervolgens naar beneden te scrollen en op de link naar ‘Page 2’ te klikken.

4

Het probleem zit in een aantal structuurvisies binnen de huidige dataset waarin een door de API “verplicht” deel van de informatie ontbreekt. Je kan er nu omheen werken door de planType parameter mee te sturen en dan iets te kiezen dat geen structuurvisie is.

Het relevante stuk OAS hiervoor is:

planType:
  name: planType
  in: query
  required: false
  description: "Filteren op type plan"
  schema:
    type: string
    enum:
    - 'uitwerkingsplan'
    - 'wijzigingsplan'
    - 'inpassingsplan'
    - 'beheersverordening'
    - 'bestemmingsplan'
    - 'exploitatieplan'
    - 'tijdelijke ontheffing buitenplans'
    - 'omgevingsvergunning'
    - 'projectbesluit'
    - 'reactieve aanwijzing'
    - 'gerechtelijke uitspraak'
    - 'voorbereidingsbesluit'
    - 'provinciale verordening'
    - 'aanwijzingsbesluit'
    - 'amvb'
    - 'regeling'
    - 'structuurvisie'
    - 'rijksbestemmingsplan'
    - 'buiten toepassing verklaring beheersverordening'

We zijn ook hard bezig om dit soort fouten in de dataset op te lossen. In theorie zit er eind van de week een dataset achter de API waarmee deze specifieke fout in ieder geval niet meer voor zou moeten komen.

2 likes
5

De dataset is zojuist vervangen. De oorzaak van de HTTP 500 is hiermee verholpen.

Mocht je alsnog tegen problemen aanlopen, horen we dat graag.

1 like
6

Dankjewel Robin!