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

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