SL Transport, fel i dokumentationen
Har hittat en felaktighet i dokumentationen för nya SL Transport på https://www.trafiklab.se/api/trafiklab-apis/sl/transport/.
Har specifikt tittat på endpointen /sites, men det ser ut att vara samma problem på alla endpoints.
I beskrivningen står det att http-headern "Content-Type" krävs, medan det i exemplet finns denna inte med utan där används istället headern "accept".
I verkligheten krävs "Content-Type", vilket gör att Execute-knappen vid exemplet inte fungerar, och det går inte heller att använda curl-frågan vid exemplet.
Har specifikt tittat på endpointen /sites, men det ser ut att vara samma problem på alla endpoints.
I beskrivningen står det att http-headern "Content-Type" krävs, medan det i exemplet finns denna inte med utan där används istället headern "accept".
I verkligheten krävs "Content-Type", vilket gör att Execute-knappen vid exemplet inte fungerar, och det går inte heller att använda curl-frågan vid exemplet.
Följ inlägget
3
följare
Märkligt att den genererar ett curl-kommando med "accept" headern, för även i OpenApi dokumentationen är det Content-Type som har specificerats. Vi gräver lite i vad som orsakar detta.
Anledningen till att testfunktionen inte funkar (än) är att SL inte har rätt CORS headers i API-svaret, något som vi har informerat om och som förhoppningsvis kommer åtgärdas snabbt.
Hälsningar,
Bert
CORS headers kommer läggas till i framtiden, accept-headern ska undersökas av SL då jag misstänker att det är en liten bugg i API-implementationen och att API:et borde acceptera "Accept" headern istället för content-type.
Hälsningar,
Bert
Nu kör jag med både "Accept: application/json" och "Content-Type: application/json" vilket den accepterar, så jag är på den säkra sidan även om de rättar till API:et.
SL har bekräftat att de kommer rätta headern.
Hälsningar,
Bert
content-type: application/json; charset=UTF-8; indent="false"
Enligt https://www.rfc-editor.org/rfc/rfc8259#section-11:
'Required parameters: n/a'
'Optional parameters: n/a'
'Note: No "charset" parameter is defined for this registration."'
Så det är inte giltigt att ha med "charset=UTF-8" där. Inte heller indent="false", vad nu det skulle betyda, om jag förstått rätt. Korrekt är att helt enkelt bara ha "content-type: application/json" i responset.
Som tidigare personer sagt så är det helt galet att kräva content-type i requesten i och med att det är en GET request som inte innehåller något body.
Hälsningar,
Bert