Archief - API PHP?

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
k

koebeest

Legacy Member
Hey,

Ik werk hier momenteel bij een bedrijfje dat graag haar kassasystemen online zou laten functioneren aan de hand van hun databases. Nu heb je bijvoorbeeld bij hen de tabel voorraad op een centrale server en daarop zouden ze dus een API willen maken (eigenlijk een klasse) in PHP die externe gebruikers, op andere locaties kunnen aanspreken. Zo zouden die gebruikers getVoorraad("street one") moeten kunnen doen . Zij krijgen dan als output een tabelletje met enkel street one producten. Kan dit zomaar, of hou zouden jullie zo'n API achtig iets maken?

Greetz


Jens
T

Tyfius

Legacy Member
Ja en neen.

Jij draait dat PHP script op jouw webserver. Dan kan iemand anders niet zomaar die functie aanroepen, dat moet via een request gebeuren. Zij roepen dan vanuit hun script de pagina http://www.example.com/request.php?request=getvoorraad&param=streetone op. Jij verwerkt dan die request en print de correcte data naar de webpagina die zij dan analyseren.

Wil jij dat PHP script aan de klant bezorgen gaat dat wel, maar dan moet je er mee rekening houden dat iedereen de broncode van dat PHP bestand kan lezen en dus ook het wachtwoord waarmee je naar de database verbindt. Of jij moet in jouw PHP script die request.php oproepen en dat zo afhandelen.

Een andere (en soms iets meer propere oplossing) is het gebruik van SOAP.
B

BuZz.LiGhTYeAr

Legacy Member
Ik neem aan dat die centrale dbserver niet via het internet toegangelijk is? Anders snap ik het probleem ook niet.

Je moet een extra webserver opzetten met daarop PHP, .NET, whatever... die moet toegangelijk zijn voor de gebruikers, met password protection etc. Aan de hand van welke db je gebruikt kan je dan requests gaan maken via PHP, .NET, whatever...

Wil je dat gebruikers via een desktop based prog naar de database gaan, dan maak je best webservices aan op je webserver en krijg je XML prints terug.
L

Lord Kveldulv

Legacy Member
Op het werk hebben wij al zo'n apps geschreven voor klanten die een realtime connectie hebben met hun leveranciers. En wat altijd terug komt is XML of iets dat er op lijkt. Of dat nu leveranciers zijn uit België, Frankrijk of Zuid-Amerika, over iets anders dan XML wordt er niet gepraat als de API moet vastgelegd worden.
Dat is veruit het gemakkelijkste en geeft u ook een grote flexibiliteit.
Een simpele opstelling is bijv als volgt. Op de centrale server draait ge uw DB en een webserver. De taal waarin ge uw code daarop schrijft heeft geen belang. Een client kan dan een request doen naar een specifieke pagina. Of dat nu met post of get parameters is. Of ge stuurt daar als client al een XML query door. Uw code gaat adhv die query dan de data uit de DB ophalen en print dat uit als XML. Het is dan aan de client om die XML te gaan parsen. That's it.
Je moet natuurlijk ook nog wel aan de beveiliging denken. En ik weet niet hoeveel data er in uw DB zit en hoeveel clients tegelijk gaan queryen maar ik heb al meermaals ondervonden dat bij grote hoeveelheden zelfs een monster van een server door de knieën kan gaan. Voor een aantal leveranciers moeten wij de productstatus zelfs cachen. Aankopen gebeuren wel realtime. Dan kunt ge wel voor het probleem komen te staan dat het product niet meer op voorraad is. Maar het was dat of die leverancier verliezen want die wilden hun server niet upgraden.
Het principe is in feite poepsimpel maar er kunnen heel veel praktische problemen onstaan.
k

koebeest

Legacy Member
Door de knieën zal de server niet gaan want elke database geldt maar voor 1 klant. Het hele opzet zou eigenlijk zijn dat de klant geen code meer moet schrijven buiten wat simpele gets en inserts en dus ook geen xml parser meer moet gaan gebruiken. Is dat op één of andere manier te forceren? Het bestand dat de afhandeling doet met de database staat bij ons en mag niet leesbaar zijn voor klanten.

greetz
B

BuZz.LiGhTYeAr

Legacy Member
koebeest zei:
Door de knieën zal de server niet gaan want elke database geldt maar voor 1 klant. Het hele opzet zou eigenlijk zijn dat de klant geen code meer moet schrijven buiten wat simpele gets en inserts en dus ook geen xml parser meer moet gaan gebruiken. Is dat op één of andere manier te forceren? Het bestand dat de afhandeling doet met de database staat bij ons en mag niet leesbaar zijn voor klanten.

greetz
Klik om te vergroten...

maak dan gewoon ne site met login he...
L

Lord Kveldulv

Legacy Member
Dat is juist het punt van zo'n api. Dat uw code volledig afgeschermd op uw server draait. Dat een third party via een afgesproken manier toch dingen kan opvragen vanop afstand. En daar gaat automatisch mee gepaard dat die uw api zal moeten implementeren op de manier dat hij wilt en dat u in principe geen reet kan schelen hoe. Jij hoort niet verder te zien dan uw api.
En als da een probleem is voor die 'klant' dan moet hij u maar inhuren om uw eigen api te implementeren. Maar de beste manier is dan nog steeds zoals ik eerder al uitlegde, daar veranderd niets aan.
Uw uitleg is niet voldoende om het globale idee volledig te snappen. Maar een online kassasysteem voor 1 klant? En je wilt vanaf verschillende locaties er aan kunnen? Wat wil je dan met uw api bereiken? Dat je op verschillende locatie's een desktop met apache kunt zetten die local z'n code gaat draaien maar een remote DB gebruikt? Doe dan wat Buzz zegt, 1 site met login...
k

koebeest

Legacy Member
Naja, het bedrijf waar ik voor werk maakt kassasystemen voor modezaken. De bevat een backoffice module : voorraad beheer, facturen, klanten, leveranciers,... en en kassa module: verkopen.
Nu is de bedoeling dat we ons pakket gaan uitbreiden naar webshops enzo. Alleja, onze klanten laten webshops maken voor hen maar wij willen ons database structuur niet vrijgeven. Enkel de hoognodige dingen, als zij de voorraad in hun webshop willen weergeven horen zij niet te weten uit welke tabellen al die info komt.
L

Lord Kveldulv

Legacy Member
Dan kan ik niet meer zeggen dan ik reeds in mijn eerste post gezegd heb :)
k

koebeest

Legacy Member
Oh, bedankt dan . Kan ik zeker wel iets mee doen alleen is het hele "output" XML een beetje nieuw enzo. Feit is wel dat dat ik na wat zoekwerk en vooral prutswerk er ook wel zal komen. Echter is mijn vraag natuurlijk, heb(ben) (jij/jullie) toevallig geen goede stukjes tutorial? Ik weet dat zo dingen niet geheel tutorial vorm bestaan en google een goede hulp is op mijn queste naar een API, maar een extra hulp is altijd welkom.

Bedankt!
L

Lord Kveldulv

Legacy Member
Da soort dingen heb ik meteen on the job moeten leren. Nooit een tutorial van gezien al kan je dat misschien wel ergens vinden.
Het is vrij simpel. Je krijgt een input in xml. Een bepaalde layout waaruit jij kan opmaken wat er moet gebeuren. Dan doet ge uw query en ipv dat in een array te steken en uit te printen naar html ofzo, print ge dat uit naar xml. Ge moet dan wel een goed begrip hebben van xml en dat is voor de meesten blijkbaar een probleem.
De andere partij moet dan gewoon de xml gaan parsen. Is die daar niet toe in staat zit ge met ne n00b webmaster om mee samen te werken. Good luck :p
Moest ge echt complexe dingen willen doen kunt ge het nog altijd aanpakken zoals google doet. Uw api een stap verder zetten. Die hebben ook voor de client een class die ge kunt downloaden en op uw server runnen. Maw dan schrijft ge een class die zelf al de xml queries en responses gaat opbouwen, versturen, ontvangen en parsen. Dan kunt ge wel een functie in de aard van getVoorraad() aanbieden.
Maar om eerlijk te zijn, ik zou dat enkel tegen betaling aanbieden. Het belangrijkste is nog altijd dat ge een api aanbiedt die toegang geeft tot jullie systeem, en niet dat jij zomaar de programmatorische problemen gaat oplossen voor een 3rd party dev die lui is of z'n job niet kan.
k

koebeest

Legacy Member
Ja , voor toegang tot onze databases zou een vrij behoorlijk bedrag moeten betaald worden dat is wel duidelijk. Zal wel enkele honderden euro's zijn of meer dat moet hier intern nog besproken worden. Het opbouwen van een webshop is allemaal geen probleem, dat is allemaal al klaar eigenlijk (een basis client dus) maar nu zouden alle query's moeten worden omgezet naar een systeem met XML. Naja, ik zal er mij dan eens op toespitsen hoe je juist XML gaat uitsturen. Het XML formaat is totaal geen probleem, ik had dat vak op school en ben daar goed doorgeraakt. Eventueel kunnen we dan nog een clientside parser aanbieden (basis) waar de klant dan kan op verderbouwen.

Greetz
B

BuZz.LiGhTYeAr

Legacy Member
API =/= webservices, en dat laatste is ook hetgene wat jij aanraadt Lord Kveldulv...

De code is toch nooit zichtbaar voor de gebruiker via php. De gebruiker krijgt enkel een html parse te zien van de code. Als jij output toont met dezelfde namen als je tabel, ja dat is dan jouw probleem, niet dat van PHP.

Bovendien word jouw server wel iedere keer gequeryed als er een bezoeker op de klant hun webshop komt, en dat gaat jouw server (zoals Lord al aanhaalde) wel kraken.

BTW een API voor PHP noemen ze een extension, en die worden meestal gemaakt in C/C++
k

koebeest

Legacy Member
PHP kan iedereen met toestemming tot de FTP van de webserver zien en dat is zeker niet de bedoeling. De website die onze API zal gebruiken wordt gemaakt door een webdesigner/scripter die de klant zal inhuren. Wij verzorgen enkel de connectie naar onze databases. Dus de code mag NIET op de server van de klant staan. (Elke klant heeft een eigen dedicated webserver)
B

BuZz.LiGhTYeAr

Legacy Member
praat ik zo naast de kwestie dan?

hebben klanten dan rechten op uw FTP? Zoniet, wat is het probleem?

als ik ne ajax request doe is dat via http, geen ftp of wat dan ook. Zorg gewoon dat je een webserver hebt draaien met daarop php scripts die xml outputten.
k

koebeest

Legacy Member
Uw uitleg klopt gewoon niet, of hij is gewoon niet duidelijk. Je gaat beweren dat ik gewoon mijn PHP code op de server van de klant kan smijten. Als ik dat ga doen kunnen zij gewoon via FTP die php file downloaden en openen met bijvoorbeeld kladblok. Mijn bedoeling is een volledige klasse/API die de klanten de mogelijkheid geeft om een request te doen en dat ik ze dan bepaalde XML data geef uit hun database. Het is dus wel degelijk hun database, maar die draait "lokaal" bij ons dus ze zien de databasestructuur niet. Dit moet ook zo blijven, ook al willen ze een webshop via ons systeem.

Het is ook geen optie dat wij de webshop voor hen maken en wij hem lokaal draaien. Wij zijn scripters/programmeurs en geen webdesigners. Als de klanten een webshop willen moeten ze daar maar iemand voor inhuren :)
B

BuZz.LiGhTYeAr

Legacy Member
Ik praat niet over de klant hun FTP. Ik praat over een webserver die jij beheert waarop jouw code staat, zonder FTP access voor de klant.

Ik stel voor dat je eens wat opzoekt over AJAX.
e

el shorty

Legacy Member
ik snap eigenlijk ook al de hele discussie en uitleg niet die koebeest geeft, mor bon: zal aan mij liggen

Imo simpelste: parse het vioa php op je eigen server. Maak een xml output aan: dan kan die bij hen ook lokaal makkelijk opgevraagd worde n(simplistisch uitgelegd!!!)
k

koebeest

Legacy Member
Jopz, maar kan je op die manier ook dingen terugsturen (update query's al het ware :))
W

WHiSPy

Legacy Member
el shorty zei:
ik snap eigenlijk ook al de hele discussie en uitleg niet die koebeest geeft, mor bon: zal aan mij liggen

Imo simpelste: parse het vioa php op je eigen server. Maak een xml output aan: dan kan die bij hen ook lokaal makkelijk opgevraagd worde n(simplistisch uitgelegd!!!)
Klik om te vergroten...

Euh, je hebt net 'n webservice beschreven...

Er wordt hier wel veel naast mekaar gepraat precies.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan