API
API'er er blevet en stor del af det moderne internet, og er en meget praktisk måde at tilgå og behandle/persistere data på. Til dette projekt, kom vi frem til at det kunne være meget smart, hvis alle vores platforme havde et fælles indgangspunkt til databasen. På den måde skulle der ikke laves ~3 unikke implementationer, men i stedet bare en som kunne få al opmærksomheden. Tanken med API'en var så, at clienten (hjemmeside, iOS app, Android app, osv.) kunne hente bibelteksten fra API'en, så brugeren altid kunne have den nyeste bibeltekst på sit device, fremfor at det løbende skulle opdateres. I tilfælde af at 'Den Frie Bibel' også vil gøre API'en offentlig, vil andre også kunne bruge API'en til at lave deres egen platform, hvori man vil kunne læse teksten.
API'en kan pt. bare kaldes igennem det samme domæne som hjemmesiden ligger på. I dette eksempel kører hjemmesiden bare lokalt på min computer, så jeg bruger IP'en 127.0.0.1 samt port 30000, da det er den jeg har valgt (Se blogopslag om udrulning). Der er en række forskellige endpoints for API'en: bible, comment, auth/login, auth/register, auth/authenticate og auth/logout. Her vil jeg bare gå igennem et simpelt eksempel med bible.
Brugeren kan angive en bog og et kapitel, som de gerne vil have teksten var, og så sender API'en teksten tilbage som en JSON-fil, med alt det indhold der er relevant. Brugeren kan også lade vær med at angive et kapitel, og i stedet bare skrive "all" ved "book", får de i stedet en liste af alle bøger i bibelen.
I backenden tjekker API'en så først om requesten giver mening og om den er sikker. Hvis det skulle være tilfældet, henter den al det relevante data fra en række tabeller i en MySQL-database.
API'en tjekker f.eks. om "book" og "chapter" indeholder nogle SQL keywords, og om de indeholder andet end bogstaver og tal (f.eks. er symboler og mellemrum ikke tilladt). Hvis disse parametre ikke lever op til kravene, sender API'en en fejlbesked, så brugeren ved hvordan de kan fikse deres request.
API'en tjekker også om clienten bruger den rigtige HTTP method. Det ville ikke give mening, hvis en POST og gav listen af bøger.
Tidligere hentede API'en ikke teksten fra databasen, men i stedet fra tekstfiler som lå i selve Next.js projektet. Der var den "eneste" sikkerhed, at den tjekker om filen eksistere, inden den sendte filen tilbage. En hacker ville derfor i princippet kunne bruge ../ til at navigere tilbage på computeren, og så hente andre filer. Jeg tvang den dog til at bruge .json filer, men man ville i princippet kunne tilgå alle .json filer på min computer, hvis jeg ikke havde ændret det.
Her er også en række eksempler på de fejlbeskeder API'en kan sende tilbage, hvis brugeren skriver noget forkert ind i parameterne. Brugeren får også en passende HTTP kode sendt tilbage, så de har en idé om hvad der er gået galt.
