Till senaste kommentaren

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.
Johan Carlberg

Kommentarer

  • Hej Johan,

    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
    Bert på Trafiklab
  • Hej Johan,

    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
    Bert på Trafiklab
  • Håller med om att de borde använda "Accept" istället, "Content-Type" i en GET är lite konstigt.

    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.
    Johan Carlberg
  • Reagerade också att Content-Type krävde på GET så vore kanon om SL kunde kolla på detta. Känns helt bakvänt 🙂
    säl
  • Hej!

    SL har bekräftat att de kommer rätta headern.

    Hälsningar,
    Bert
    Bert på Trafiklab
  • På samma tema... Jag ser att responset har följande header:

    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.
    Emil

Kommentera eller skriv ett nytt inlägg

Ditt namn och inlägg kan ses av alla. Din e-post visas aldrig publikt.