[youheardit]

Tjena WN!

Ska nu bygga ett API till företagets nya system för ehandel.
Som det ser ut nu verkar det blir bra, men vill höra mig lite för av vad andra han som tips, mest för säkerheten.

Kommer att programmera i PHP mot mysql.

Och sql_injections är inga problem.

tacksam för lite tips =)

[allstars]

Loggning är rätt viktigt och att returnera relevanta felmeddelanden - åtminstone i tidigt skede

[studiox]

Du kan ju ge oss en hint om i vilken riktning du behöver tips?

Det enda generella jag kan ge är att SOAP är dött och RestFUL är kung.

[youheardit]

Ursprungligen postat av allstars

Loggning är rätt viktigt och att returnera relevanta felmeddelanden - åtminstone i tidigt skede

Låter logiskt... =)

Ursprungligen postat av studiox

Du kan ju ge oss en hint om i vilken riktning du behöver tips?

Det enda generella jag kan ge är att SOAP är dött och RestFUL är kung.

Tänker inte köra några färdiga system, har byggt eshopsystemet från grunden och API't förblir också från grunden.

Det jag mest har funderingar kring är hur jag ska skicka data från client till basen.

Just nu bygger jag för POST med md5 och secret keys osv. (liks de flesta payment api's).

[tartareandesire]

Ursprungligen postat av youheardit

Låter logiskt... =)



Tänker inte köra några färdiga system, har byggt eshopsystemet från grunden och API't förblir också från grunden.

Det jag mest har funderingar kring är hur jag ska skicka data från client till basen.

Just nu bygger jag för POST med md5 och secret keys osv. (liks de flesta payment api's).

SOAP och REST är inga färdiga system utan just metoder för att skicka data och bygga upp webbtjänster.

Att SOAP är dött håller jag inte riktigt med om. Det är fortfarande väldigt många som använder sig utav det.

Vilken säkerhet som krävs beror ju också helt på vad det är för information som skickas via API:t.

[Conny Westh]

Mitt tips är att dela upp funktionaliteten i ett API i flera helt fristående komponenter/klasser där det är möjligt. Detta är bra för den som vill använda enstaka delar.

Exempelvis, egen klass/komponent för::

- Betalningsmodul till varje enskild betalningsförmedlare som Paypal, Payex, osv... Kanske med en egen abstractklass så alla får samma gränssnitt mot användande komponent. Tänk på att det ska vara möjligt att använda flera betalningsmoduler i applikationen hos en installation.
- Shopping cart
- Kommunikation med databasen (sä det blir lätt att byta databasmotor)
- GUI går alltid genom en presentationskompont så GUI inte går direkt mot databas

Försök i möjligaste mån att isolera olika skikt som exempelvis:

- GUI (HTML/IMAGES) - Detta skikt ska kunna bytas helt för olika devices som Mobiltelefon, PC, Mac, Bankomater m.m.
- Presentationslager (GUI går alltid genom detta lager) Kan återanvändas av alla GUI-varianter.
- Dialogkontroll (navigering)
- Processlogik (i programkoden)
- Databas mappning (ORM=Object relational Mapping, typ hibernate)
- Stored procedures, Datamodell m.m.

Se till att det är TYDLIGA gränser mellan varje skikt och att alla anrop sker uppifrån och neråt i hiarkin, exempelvis ska processlogiken aldrig ska aldrig anropa dialogkontrollen, för då har man tänkt fel.

Se till att gränssnitten mellan varje skikt är konsekvent likadant så det blir enkelt att byta ut enskilda komponenter/skikt.

Om du använder externa komponenter som inte är delar stora välkända APIer, typ en tredjeparts GUI-Grid eller en Async-komponents från 3:e part så ska man ha för vana att bygga Wrapper(omslags-)-komponenter runt dem, så det blir enkelt att byta om det skulle behövas.

Se även till att ditt API stöder en välkänt applikationsmönster (eller om du bygger ett revolutionerande bättre själv). Ett vanligt förekommande som har många år på nacken är Model-View-Controler eller MVC.



Tänk också på att komponenter eller klasser får begränsade och lätt överblickbara ansvarsområden, så det blir lätt att förstå vad de anvarar för.
Tänk på att ALDRIG ha printsatser till skärmen i andra moduler än GUI-skiktet.

[youheardit]

Tack Conny och tartareandesire för bra svar.
Det som ska använda API till är beställningar. Någon kopplar upp sig till vårt API och skickar oss en beställning/order på våra produkter.

[Conny Westh]

Ursprungligen postat av youheardit

Tack Conny och tartareandesire för bra svar.
Det som ska använda API till är beställningar. Någon kopplar upp sig till vårt API och skickar oss en beställning/order på våra produkter.

Då känns det naturligt att du ska ha en Order-komponent och en komponent som endera heter Artikel/Katalog/Prislista.

Frågan är vad du vill at din användare ska kunna göra, exempelvis:


I Varukorgs-komponenten (Hålla reda på artiklar innan order skickas)
- Välja artikel
- Ta bort artikel
- Hämta saldo i varukorgen


Kassa-komponenten
- Betala för innehållet i varukorgen
- Välj betalningssätt
- Registrera kund-/leveransuppgifter


I orderkomponenten
- Se alla befintliga order som denna kund har
- Lägga till nya beställningar
- Ta bort gamla beställningar som är genomförda
- Avbeställa ännu ej expedierade order


i Katalog-komponenten (Används för att hitta en specifik artikel)
- Lista alla artiklar av en viss kategori
- Lista alla artiklar i hela katalogen
- Lista artiklar med fritextsökning


Prislista-komponent ()
- Lista priser per artikel för en viss kund/avtal vid en viss tid
- Hantera tillfälliga priser/kampanjer


I Artikelkomponenten
- Hämta ett komplett Artikelobjekt om man har artikelnummer

[studiox]

Ursprungligen postat av tartareandesire

Att SOAP är dött håller jag inte riktigt med om. Det är fortfarande väldigt många som använder sig utav det.

Vilken säkerhet som krävs beror ju också helt på vad det är för information som skickas via API:t.

Jag skrev mitt inlägg helt baserat på ingen information alls (som jag också skrev) - Poängen var att visa att det underlättar om trådskaparen berättar vad det är för API man vill bygga :-)

Själv bygger jag mina flesta API på HTTP POST/GET/DELETE - RestFUL är ju ingen standard egentligen utan det är väl mer ett sätt att försöka definiera något som folk har byggt i 100 år och vara lite "hippa" när det blir allt vanligare med anrop av webbtjänster direkt från klienter (via JS exempelvis)

Man vill ju inte bygga en SOAP klient i JS, men kör man serverside så tycker jag soap är otroligt smidigt även om det är lite onödigt mycket overhead.

[dAEk]

Är det ett publikt API eller ett internt? Är det internt är det mycket lättare att göra förändringar men om du exponerar ett API till allmänheten är du mer eller mindre låst och måste - eller kanske bör i allra högsta grad - vara bakåtkompatibel.

Försök att jobba mycket med interfaces så får du i grunden ganska stor flexibilitet. Dessutom kan du köra TDD om du vill och på så sätt kvalitetssäkra API:et.

Tänk också på det som Conny skriver: definiera olika lager och ansvarsområden. Det kan t.ex. inte anses vara bra att låta klienterna skicka info direkt till datalagret som du var inne på i ett av inläggen ovan. Klienterna borde snacka med en service som snackar med ett repository som snackar med en datakälla. På så sätt kan du byta datakälla eller flytta den utan att klienterna påverkas alls.

Det svåra är att komma på bra och konsekventa metoder som man exponerar. Väldigt ofta kommer man på att man missat något när projektet har varit uppe i drift ett tag.