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
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".


Jeg læste det også som du skrev om sikkerhed :-)
Hvis det handler om at lave CRUD operationer ville jeg altid vælge rest, hvis jeg skulle lave operationer ville jeg vælge Soap løsningen.

Når REST er en arkitektur giver det heller ikke mening at sige at man får noget men ikke noget andet. Det er jo blot et spørgsmål om at implementere din arkitektur således den passer til dit behov. Hvorimod ved SOAP er protokollen og arkitekturen allerede fastlagt.

Jeg tror der hvor vi snakker forbi hinanden er at når jeg siger at REST er en arkitektur, ligeså vel som client server er en arkitektur. Det er ikke en teknologi. Du siger cowboy, og du ikke får kvittering fra dit kald? Det er jo det HTTP Status koden er der til, der kunne man implementere det som at HTTP Status Code 200 (OK) betød at den var udført?

P.S. de eksempler fra den artikel du linkede til er rigtig dårlige, der er det svært at se hvordan man skelner mellem metode og resurse. Den fra Wiki er bedre da det er bedre tydeliggjort i form af url strukturen.



Indlæg senest redigeret d. 01.11.2012 14:00 af Bruger #2730
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 (har intet med sikkerhed at gøre) for at kontrollere om kommunikation er gennemført. 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

Edit: udspecificeret "sikker metode".



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