Onderwerp: Api

Hoi WHT'ers,

Ik ben een vrij gevorderde PHP/MySQL programmeur, maar af en toe lees ik wat over API's en heb ik geen idee hoe ik me dat moet voorstellen. Ik begrijp heel goed het API principe en ook wat het moet doen. Maar vraag me vooral af hoe je je eigen website via een API van Openprovider zou kunnen koppelen hun systeem en geautomatiseerde aanvragen zou kunnen doen? Hoe ziet zo'n 'script' eruit? En hoe zit het met de beveiliging van zo'n API en het gebruik daarvan?

Ik zou het erg op prijs stellen als iemand me hier uitleg over kan geven, want ik ben erg nieuwsgierig en leergierig...

Alvast bedankt in ieder geval!
Steven

Voor zover ik het begrijp - API is niks meer of minder dan set rules hoe applicatie met andere applicaties moet omgaan. Mss beter hier uitgelegd:

http://www.webopedia.com/TERM/A/API.html

Dus, het is niet zozeer code zelf, maar meer als:

Als ik A tegen server (via API op die en die manier) zeg, dan zou ik terug B verwachten (via API op weer van de voren voorgesteld manier).

API is eigenlijk voor 'grote' projecten, het manier om echte code beveilgd te houden (en ook geheim), maar alsnog mogelijkheid aan derden te geven om van dezelfde code gebruik te maken (Google API als mooiste voorbeeld).

Hopelijk konde ik je wat helpen

Groetjes,
Aleks

Dit kan op alle denkbare manieren!

Bij SIDN stuur je emails in een bepaald template naar hostmaster@.., zij sturen jou weer emails terug die je moet parsen.

Bij RRPproxy wordt een SSL connectie opengehouden, en kun je er verzoeken in tekstvorm heen sturen, het antwoord komt weer in tekstvorm terug.

Bij EURid maak je een korte SSL verbinding naar een tcp poort.

Bij ons maakt de client een HTTPS verbinding naar onze website, POST daar een xml-document heen, en krijgt een xml-document met het resultaat terug.

Je kan het zo gek niet bedenken. Ik heb het gewoon over HTTP(S) gemaakt omdat het posten over HTTP in vrijwel elke taal zeer simpel te doen is, en het lezen/schrijven van XML ook. Daarnaast hoeven we dan ook geen speciale server daemon te draaien, de webserver kan het gewoon afhandelen met een zooi webscripts. Hoe het bij Openprovider gaat weet ik niet.

Beveiliging is meestal geregeld door SSL en een login/password of secret key combinatie.

Openprovider gaat op dezelfde manier als SIDN, met e-mailformulieren. Alleen maakt Openprovider al gebruik van handles.

- Dennie

op werkt ook met xml geloof ik...

http://www.openprovider.nl/webimages/oal.gif

Bedankt allemaal, ik begin het een stuk beter te begrijpen!

Ik ben gelijk even aan de slag gegaan en het is gelukt om variabelen + een file te posten via HTTP door fsockopen() te gebruiken in PHP. Het is nog niet gelukt om een SSL verbinding te openen, maar misschien komt dat wel doordat ik op die website alleen het standaard certificaat van Plesk heb ;-)

Ik zat al een tijd na te denken over hoe je dat met de beveiliging zou moeten doen, maar als je klanten die gebruik maken van jou API inloggegevens op jou server hebben staan. Dan kunnen ze die zelf in hun script opgeven en die kan jij dan weer op je server verifieren. Als die gegevens over een internet lijntje gaat is het natuurlijk wel netter om SSL te gebruiken

Heel erg bedankt! Als jullie nog tips hebben hoor ik het graag!

Oorspronkelijk geplaatst door thrunx

Ik ben gelijk even aan de slag gegaan en het is gelukt om variabelen + een file te posten via HTTP door fsockopen() te gebruiken in PHP. Het is nog niet gelukt om een SSL verbinding te openen, maar misschien komt dat wel doordat ik op die website alleen het standaard certificaat van Plesk heb ;-)

Via welke port heb je geprobeerd een SSL verbinding te maken? HTTPS gaat meestal over port 443 ipv 80.

Ik zat al een tijd na te denken over hoe je dat met de beveiliging zou moeten doen, maar als je klanten die gebruik maken van jou API inloggegevens op jou server hebben staan. Dan kunnen ze die zelf in hun script opgeven en die kan jij dan weer op je server verifieren. Als die gegevens over een internet lijntje gaat is het natuurlijk wel netter om SSL te gebruiken

Je zou de beveiliging net als bij TransIP kunnen doen: met een inlognaam én een MD5 hash die berekend is uit inlognaam:wachtwoord@IP. IP is van de server die verbinding probeerd te maken met jouw API. Aan jouw kant komt de request binnen en zoek je het wachtwoord bij de inlognaam in je database en bereken je de MD5 hash opnieuw. Als jouw hash overeenkomt met die van de klant, dan is er succesvol ingelogt. Zo blijft het wachtwoord beschermd, omdat MD5 tot nu toe nog niet is te kraken.