Skriver en API i PHP. Mangler lidt idéer

Tags:    php api session soap sikkerhed

<< < 12 > >>
Hejsa.

Okay jeg sidder på 5. semester på datamatikerstudiet, og har fået den lidt alternative idé at jeg vil skrive min egen API.

Jeg har allerede udviklet et lille Backoffice/ERP - i PHP vel at mærke. Alting er derved webbaseret.

Den første idé er at eksterne udviklere skal have mulighed for at kode op i mod min/vores API, således at de kan trække og skrive data fx via SOAP. Det er der en masse gode sikkerhedsaspekter i, til rapporten. Denne del tror jeg at jeg har nogenlunde på plads.

Min anden idé er at give eksterne udviklere mulighed for at lave et modul der installeres på vores server. Og jeg havde tænkt mig at sådan et modul tog afsæt i en klasse, der skal implementere et interface der ligger hos os, derudover en valideringsproces der også er bundet op på nogle kontrakter. Så kunne min Controller (bruger MVC) validere dette modul og eksekvere det, altså indefra.

Spørgsmålet er så:
- Giver det overhovedet nogen mening, fordi det eksternt udviklede indhold vil jo få adgangs til alle sessionsvariabler - Det er jeg ikke interesseret i !
- Hvordan kan jeg køre denne klasse "myModule implements iModule", og sørge for at den er fuldstændigt enkapsuleret?
- Kan man køre en funktion med begrænsede rettigheder eller lidt "sandboxed" i PHP 5?
- Er der andre aspekter jeg overser? (Det er der helt sikkert)

Alternativet er selvfølgelig kun at tillade at et modul indeholder noget kode Controlleren selv decoder og forstår. Noget hjemmelavet XML-agtigt fx.

Edit: Modulerne ligger på vores PHP server som en del af viewet. Og køres derfra, derfor får de som udgangspunkt fulde rettigheder.

På forhånd tak



Indlæg senest redigeret d. 01.11.2012 08:57 af Bruger #16824
12 svar postet i denne tråd vises herunder
2 indlæg har modtaget i alt -4 karma
Sorter efter stemmer Sorter efter dato
Hvis du tillader, at eksterne udviklere smider PHP kode på din server, så har de adgang til alt. Læs/skrive filer, oprette netværksforbindelser, og så videre...nok ikke noget, du er interesseret i.

Det, du kan gøre, er, at levere et SOAP/REST/whatever API, som eksterne udviklere kan kode op imod. De kan så registrere URL'er, som kan håndtere "events"...så istedet for at du kalder
Fold kodeboks ind/udKode 
så udfører du:
Fold kodeboks ind/udKode 


Så bliver koden ikke udført på din maskine.



Indlæg senest redigeret d. 01.11.2012 09:48 af Bruger #2695
Hvis jeg var udvikler, ville jeg foretrække en REST API med JSON som returværdi :)
Så kan du evt. lave dit eget API Key eller Token system.

Lidt i stil med blandt andet Facebook Graph API.



Tusind tak for input.

Jeg har et token system på plads, og overvejede også både REST og SOAP.

I min situation vil udviklere, indenfor et begrænset scope, få lov til at ændre kompleks data. Er REST at foretrække over SOAP?



Indlæg senest redigeret d. 01.11.2012 10:24 af Bruger #16824
Tusind tak for input.

Jeg har et token system på plads, og overvejede også både REST og SOAP.

I min situation vil udviklere, indenfor et begrænset scope, få lov til at ændre kompleks data. Er REST at foretrække over SOAP?


Personligt foretrækker jeg REST.
Der er man ikke tvunget til at benytte XML, og så er det dejligt nemt at man kan teste REST GET-resources direkte i sin browser (:



Jeg tror det bliver SOAP jeg bruger. Da en af de primære handlinger bliver at administrere lagerbeholdning (hvilken skal stemme!), mellem backofficet og en webshop fx.

Jeg takker og bukker.



REST og SOAP skal bruges i hvert sit scenarie.

SOAP er hvad REST ikke er. :)

Man bruger SOAP bl.a. til økonomi grundet SOAPs struktur er beregnet til dette. Det er REST ikke. I SOAP protokollen ligger indbygget at server og client kontrollerer hinandens requests. Ved SOAP iværksættes en overførsel og efterfølgende kontrolleres at overførslen gennemføres. F.eks. ved en konto overførsel går det ikke at man overfører penge flere gange.

REST er den direkte modsætning, hvor man i REST blot overfører og håber på at overførslen er gået igennem.

Så REST er lidt en cowboy kommunikation, hvor SOAP er den sikre metode. Dette er blot en af forskellene mellem SOAP og REST. Så jeg vil anbefale at du læser det om hvad der er hvad:

Læs: http://en.wikipedia.org/wiki/SOAP og http://en.wikipedia.org/wiki/REST


Der er massere af banker der benytter REST fremfor SOAP. SOAP er på ingen måde mere sikker end REST.
SOAP har en indbygget security-method (WS-Security), som udelukkende blev lavet da SOAP over HTTP ikke er et krav.
REST derimod benytter sig af HTTP eller HTTPS protokollen og har derfor ikke brug for en sådan sikkerhed indbygget. HTTP protokollen understøtter Basic Auth, Digest Auth, SSL og OAuth.

Der er mange misforståelser angående SOAP/REST sikkerhed.



REST og SOAP skal bruges i hvert sit scenarie.

SOAP er hvad REST ikke er. :)

Man bruger SOAP bl.a. til økonomi grundet SOAPs struktur er beregnet til dette. Det er REST ikke. I SOAP protokollen ligger indbygget at server og client kontrollerer hinandens requests. Ved SOAP iværksættes en overførsel og efterfølgende kontrolleres at overførslen gennemføres. F.eks. ved en konto overførsel går det ikke at man overfører penge flere gange.

REST er den direkte modsætning, hvor man i REST blot overfører og håber på at overførslen er gået igennem.

Så REST er lidt en cowboy kommunikation, hvor SOAP er den sikre metode. Dette er blot en af forskellene mellem SOAP og REST. Så jeg vil anbefale at du læser det om hvad der er hvad:

Læs: http://en.wikipedia.org/wiki/SOAP og http://en.wikipedia.org/wiki/REST


Nope!
SOAP og REST er to sider af samme sag (alt så webservices - men der ophører det stort set også).

Soap er en teknologi og REST er en arkitektur.

Med soap mapper du et funktionskald på serveren og du får så et svar tilbage. Med REST mapper du en resurse og alt efter om du bruger HTTP kommandoerne GET/POST/PUT/DELETE skal du reagere anderledes.

I Soap vil du have en metode der hedder HentBrugere(5); (alle brugere i gruppe 5) og i REST vil du bede om en tilstand/resurse: mitdomæne.dk/brugere/5
REST bruger det der er indbygget i HTTP protokollen og er således en arkitektur beslutning (at man vil mappe url til resurser og reagere på http kommandoer).

REST er langt at foretrække da alle nemt kan bruge den uden at skulle lave krumspring med SOAP (XML) og alt muligt, den er også meget mere robust i forhold til ændringer i interfacet.



Indlæg senest redigeret d. 01.11.2012 12:23 af Bruger #2730
Brian har du ikke lige modsagt dig selv? :)

Endvidere tror jeg at det vil være godt at læse: http://spf13.com/post/soap-vs-rest/



Det tror jeg ikke :-) Hvor skulle jeg det?
Her er lidt om REST: http://en.wikipedia.org/wiki/Representational_state_transfer

Der står også lidt om forskellene. Husk at REST er en arkitektur og ikke en teknologi.

Ang. dit link, så skriver han det samme som jeg skriver:

"REST is focused on accessing named resources through a single consistent interface" <-- her fokus på "named resouces"

og

"SOAP is focused on accessing named operations, each implement some business logic through different interfaces" <-- her fokus på "named operations"

Når man laver REST over internettet (som er det mest normale) er det typisk ved at bruge HTTP protokollens metoder. Se wiki artiklen.

P.S. ved REST bestemmer du også selv hvad der skal returneres fra din web service. Normalt er det noget XML,men der er intet i vejen for at det kan være almindelig text, JSON eller dit eget hjemmelavede binære format.



Indlæg senest redigeret d. 01.11.2012 13:21 af Bruger #2730
Så tror jeg både du og Rasmus har misforstået mit indlæg, da det jeg skriver ikke handler om sikkerhed. :)

Det handler i bund og grund om at SOAP bruger "tid" på at sikre et request er gennemført. I SOAP benyttes der kontrol requests for at sikre at kommandoen (den første request) er gennemført korrekt. Det svarer lidt til det lille barn der sidder på bagsædet og spørger "Are we there yet?". :) Hvor REST er den direkte modsætning. I REST bruger man ikke førnævnte tilgang.

Under REST bruger man cowboymetodologi, skyder og håber man rammer første gang, hvor SOAP er "bliv ved med at skyde indtil du har ramt".

Yderligere, når du mener at han skriver det samme som dig, må du meget gerne forklare hvor du mener at REST og SOAP er to sider af samme sag (webservices), når der på siden http://spf13.com/post/soap-vs-rest/ står skrevet:
Though SOAP is commonly referred to as “web services” this is a misnomer. SOAP has very little if anything to do with the Web. REST provides true “Web services” based on URIs and HTTP.


Selv skriver du "Soap er en teknologi og REST er en arkitektur. ". Så mit spørgsmål ligger lidt i, hvad er det der gør at du grundlæggende ikke er enig i min udmelding: "SOAP er hvad REST ikke er".



Indlæg senest redigeret d. 01.11.2012 13:35 af Bruger #10216
<< < 12 > >>
t