Designe profesjonelt API?

[jappadu]

Hei,

 

Jeg holder på å lage et API til et CRM-system med rammeverket, Slim.

 

API-et skal innholde:

• Data fra MariaDB
• Rettigheter 

 

Hva er den beste måten å designe dette på i API-verden? Jeg vil prøve å unngå å gå i programmeringsfellen, hvor man lager sin egen logikk. 

 

Takk på forhånd

Endret 12. januar 2019 av webliz

[Crowly]

Søk etter "rest api", bør gi mye informasjon om hvordan uri-ene bør utformes. Hvordan selve koden skal struktureres (hvilke design patterns man bør bruke) avhenger av hva systemet har behovet for å gjøre. DRY (dont repeat yourself) er kjekt. Interfaces er veldig nyttig.

[0laf]

Dersom dette skal være åpent tilgjengelig, er det viktig med sikkerhet, alle forespørsler må vaskes skikkelig.

 

Selv for et lukket system som kun håndterer kunder, bør det være noe sikkerhet, slik at systemet ikke har noen som helst mulighet for å åpne for POS-angrep eller lignende.

Som nevnt ovenfor, se på standardene for REST, SOAP og den slags, i dag bør et API returnere JSON etter min mening, og ha fornuftig oppbygging av forespørsler.

[jappadu]

Takk for gode svar. Det skal ikke være åpent. I forhold til sikkerhet. Er session og nøkkel greia da?

[0laf]

Takk for gode svar. Det skal ikke være åpent. I forhold til sikkerhet. Er session og nøkkel greia da?

 

Dersom det er eksponert mot åpent nett, altså tilgjengelig på internett eller lignende, så må det nødvendigvis låses på et vis dersom ikke alle skal ha tilgang.

Jeg ville sett på OAuth eller lignende, som er sikre systemer som brukes av alle andre.

 

I utgangspunktet kan du også sende alt over https og sende med en API-nøkkel på hver forespørsel (med POST).

For de fleste systemer vil det være nok til å hindre uvedkommende, men hvorvidt du trenger høyere sikkerhet kommer an på dataene, og hva som behandles.

Endret 13. januar 2019 av 0laf

[Crowly]

Sider som Laracasts.com og PluralSight.com (har ikke noe om php, men en god del som er språkuavhengig. Kan anbefales for C# og .net core i alle fall) har mange gode videoer om utvikling, men de koster penger. Laracasts har en del serier hvor noen av videoene er gratis / tilgjengelig for alle. Har ikke sjekket om det er tilfellet for Pluralsight, men de har en gratis trial periode.

Endret 13. januar 2019 av Crowly

[jappadu]

Takk for svar Vet noen om noen gode eksempler på ferdige web api-er i Visual Studio-prosjekter som man kan teste / lære av? 

[Emsal]

Vi bruker lumen rammeverket på jobb. Synes det fungere veldig greit. Det er som laravel bare mye mindre og kjappere. Er veldig fan av PHPstorm som IDE, men tror det koster litt.

[0laf]

Takk for svar Vet noen om noen gode eksempler på ferdige web api-er i Visual Studio-prosjekter som man kan teste / lære av? 

 

Altså, Web API er noe eget, det er faktisk definert av MDN -> https://developer.mozilla.org/en-US/docs/WebAPI

Dessverre er det også noe som heter Web API i Visual Studio, da snakker vi om endepunkter på en server forutsatt at man holder på med .NET osv.

 

Generelt er jo en API et programmeringsgrensesnitt, dersom du skal ha en API som henter data fra MariaDB og leverer dette til et CRM system, uansett om det systemet lever i en nettleser, så skal du vel ha endepunkter på en server som returnerer data fra databasen, ikke et Web API?

 

Generelt ville jeg holdt meg langt unna PHP for dette, å heller gått for Python eller ting som Node.js, sannsynligvis sistnevnte med Mongo eller Redis i stedet for Maria, kommer an på dataene og mengde forespørsler?

Er man spesielt glad i tortur, så er ASP.NET med deres "Web API" system også en mulighet?

Endret 21. januar 2019 av 0laf

[Crowly]

Vet noen om noen gode eksempler på ferdige web api-er i Visual Studio-prosjekter som man kan teste / lære av?

F.eks. https://github.com/JasonGT/NorthwindTraders

Northwind Traders is a sample application built using ASP.NET Core and Entity Framework Core

C# og .NET Core med Entity Framework gjør mye bra. Som nevnt over så har https://www.pluralsight.com mange gode opplæringserier om dette.

[quantum]

Enig i mye av det 0laf sier, men er ikke så sikker på at MariaDB (eller RDBMS generelt) er så uegna for CRM. Legger til Spring Boot (Java) som alternativ plattform for API'et. 

[0laf]

Enig i mye av det 0laf sier, men er ikke så sikker på at MariaDB (eller RDBMS generelt) er så uegna for CRM. 

 

Nei, relasjonsdatabase er nok ikke uegnet til CRM generelt, det er jo flotte greier.

 

Samtidig bør man normalt forsøke å benytte den mest effektive databaseløsning, og det må nesten baseres på dataene og forespørslene?

 

Det er veldig mye fleksibilitet i SQL, spørsmålet blir om man trenger den fleksibiliteten, eller om noe annet kan være enklere og raskere, for eksempel NoSQL som returnerer JSON direkte, og som er enkel å hente ut data fra dersom de fleste forespørsler er forholdsvis like, slik de ofte er i slike systemer som CRM ofte er bygget på?

Endret 24. januar 2019 av 0laf

[quantum]

Å få json direkte ut av databasen i dag er like "kult" som det var å få xml direkte ut av databasen for 10-15 år siden. Velg database heller utifra andre kriterier. Mongo-dbs fremste egenskap er ikke json-formatet. På en moderne plattform får man fatt i json på ganske enkle måter uansett hva databasen gir i utgangspunktet.

 

Å si at RDBMS'er fleksible i forhold til NoSQL er å sette tingene på hodet, etter min mening. RDBMS'er er rigide i forhold til mange NoSQL databaser, som f.eks. er skjemaløse, dropper integritetsgrav for å oppnå hastighet og skalering osv. Redis er en in-memory key-value-store, vanskelig å se at det er riktig match for en tradisjonell CRM-løsning. 

 

Husk at når databasen er fleksibel, da tenker jeg i første omgang på skjemaløs, så må applikasjonen også være det. Alle kunde-entitetene som skal med i en rapport har plutselig ikke de samme feltene tilgjengelig. Hvor gøy er det å kode den rapporten? Andre ganger kan skjemaløs redde dagen, bevares, men det gjelder å velge riktig verktøy til oppgaven.

 

TS vil prøve å unngå "programmeringsfellen hvor man lager sin egen logikk". Det er akkurat det mange har opplevd å måtte gjøre når de har gått for NoSQL uten å tenke seg om. Man satser på feil hest, og "plutselig" må man  kode integritetssikringskoden selv. Meningsløst, tidkrevende og feilbefengt.

 

NoSQL er fornuftig der man har krav til f.eks. skalering som en vanlig RDBMS rett og slett ikke møter. Da må man velge pest eller kolera. Eller kompromisse. RDBMS-aktige NoSQL-databaser, eller NewSQL som noen kaller seg, gjør det, og gir f.eks. "eventual integrity", databasen din vil være konsistent, men ikke til enhver tid.

 

Hvis man vil ha det lettvint uten å kompromisse så mye, er Spring Boot med Rest-api og JPA-repositories fint, da får man ut json uten å måtte kode verken SQL eller json i utgangspunktet, og så kan man gå inn med manuell kode der automagien eventuelt blir for enkel.

 

Forøvrig, hvis man er en enkelt utvikler og aldri kommer til å få hundretusenvis av samtidige brukere på applikasjonen går det an å droppe rest-api fullstendig og lage en monolitt. Vise menn (Fowler) har sagt at det kan være dumt å begynne med microervice-arkitektur fra starten. Det er ikke alt som er best-practice på enterprisenivå som er det på medium og små prosjekter. Har sett Josh Long spikre sammen demo'er av Spring Boot med Vaadin på toppen, det er selvfølgelig fordi det er en superenkel og effektiv stack å bruke.

Endret 24. januar 2019 av quantum

[jappadu]

Mye bra som blir nevnt her. Det blir nevnt at OAuth er sikrere enn API-nøkkel. Er OAuth mer omfattende å utvikle med? 

[KolsKols]

Ta en titt på å sikre APIet med f.eks auth0.

[jappadu]

Vet noen om noen gode API-prosjekter (C#) fra Github som man kan jobbe videre / endre på, slik at man er sikker på at man utvikler et korrekt API (sånn kodemessig og infrastruktur)?

Endret 4. februar 2019 av webliz

[Nichiatu]

Steg 1: Last ned Laravel med composer.

 

Steg 2: C:\> laravel new mitt-api

 

Steg 3: Legg til databaseparametere i config (.env)

 

Steg 4: vim routes/web.php

 

Steg 5: Lag endepunkter i routes/web.php (husk REST) og bruk auth middleware

 

Steg 6: $ php artisan make:controller {route}Controller

 

Steg 7: vim app/Http/Controllers/{route}Controller.php

 

Steg 8: Profitt.

 

Det er så enkelt at det nesten blir litt kjedelig. ( ͡° ͜ʖ ͡°)

Endret 14. februar 2019 av Nichiatu

[Ernie]

Et godt API bør etter min mening

• Enkelt og intuitivt å bruke
• Har funksjonalitet man naturlig forventer er en del av APIet
• Er konsistent i navngiving og konsept.
• Er hensiktsmessig for den bruken den er tiltenkt
• ...og aller viktigst av alt: er godt dokumentert i koden og ev. separat. Et godt eksempel på godt dokumentert i koden er etter min mening FreeRTOS. Hvis man ser i header-filene så ligger det enkle eksempler på bruk per funksjon. Det er utrolig nyttig, spesielt hvis man plutselig sitter der uten Internet.

[HrKristian]

Generell regel for sikkerhet:

ALDRI prøv å finne opp hjulet på nytt.

 

Sikkerhet er rett og slett er for stort fagfelt til å ta for seg alene, firmaer som står for sin egen sikkerhet har dedikerte team til dette og selv disse teamene gjenbruker andres testede løsninger.

 

Mitt forslag er å bruke et større rammeverk som Laravel, slik en annen poster foreslår. Det vil spare deg en masse hodebry.