- Detta ämne har 18 svar, 6 deltagare, och uppdaterades senast för 13 år, 9 månader sedan av
.
-
Det låter bra, då är den enkla biten gjord att påbörja standarden, då har du bara ett par hundra olika leverantörer till du ska övertala att använda din standard och bygga om sina system helt efter den.
Det var värst vad lilla myran fällde ut klorna …
Helt enkelt är det inte, men om man tittar på betalväxlar så skulle det vara fullt möjligt att skapa ett enhetligt API. I grunden finns det tre olika flöden man behöver hantera:
1. Kortuppgifterna anges på ordersidan
2. Man öppnar ett hostat betalfönster
3. Man ansluter till en check-out sida där alla kundens uppgifter finnsTransaktionsflödet för olika växlar är idag ganska likartat, men de använder helt olika parameternamn och metod för att skicka parametrar (POST, GET, XML). Några har lite mer omfattande handskakning än andra.
Dock ser jag inga tekniska svårigheter att kunna implementera all nödvändig funktionalitet i ett applikationsprotokoll. Svårigheten ligger istället i att få alla att dels enas om att det är en bra idé (många kommer att hänvisa till säkerhet) och sedan att enas om en lösning som är tillräckligt flexibel att växa i.Ett möjligt första steg kan vara att sätta upp en gateway-tjänst som sköter konverteringen.
Mot transporttjänster borde det också vara möjligt att hitta ett gemensamt språk. Man har det ju på sätt och vis via Unifaun t.ex, du kan lätt byta från Posten till DHL … men du kan inte lika lätt byta från Unifaun till Apport.
När det gäller integration mot affärssystem så blir det lite mer komplicerat eftersom de kan ha olika struktur och strategier för hur olika typer av data läggs upp (options, varianter, strukturartiklar, kunder med flera kontaktpersoner och/eller adresser). Dessutom har de ju olika mycket data, så då uppstår frågan hur man skall hantera data som finns i det ena systemet men inte i det andra.
Men någon form av standardiserad webservice hade varit bra, med möjlighet att lägga till unika data för det aktuella systemet, men att hitta den optimala strukturen kan vara ganska svårt.Saken är väl bara den att det inte finns så stort intresse från de olika aktörerna att det skall vara lätt att byta system. Genom att det blir en del teknikkostnader förenade med ett byte av webshop och/eller betalväxel så sitter kunden lite mer fast.
Å andra sidan hade ett standard API gjort att ”alla stödjer alla” redan från början, och ingen behöver avstå från en viss webshop bara för att den inte stödjer den betalväxeln han vill använda.
Men greger det är katter som har klor inte myror…..
Jag ser inte riktigt den stora grejen här tror jag.
Vi har gjort många betalväxelkopplingar och även TA kopplingar, det brukar normalt vara ca 4h jobb för en betalväxelkoppling, så för mig känns det inte som ett större problem, även om de har löst det olika….
Att däremot Bygga om system med ett antal tusen Tusen timmar bakom sig för att bara få samma funktionalitet for att folja en standard ingen efterfragar och som jag är rätt säker på att INGEN av vare sig ehandlarna eller standardmänniskorna är Villiga att betala ombyggnation av for att få likvardiga som de var innan.
Där ser jag ett problem….
Eller vad säger ni en 3-4 dubbling av webshopspriser,betalväxelkostnader och affärssystem och TA systemkopplingar, det är ni väl alla beredda att betala för att alla ska följa samma standard, och utan ny funktionalitet??? Eller hur var det???
jag garanterar att slutkunderna inte
@GregerA 17577 wrote:
Det var värst vad lilla myran fällde ut klorna …
Helt enkelt är det inte, men om man tittar på betalväxlar så skulle det vara fullt möjligt att skapa ett enhetligt API. I grunden finns det tre olika flöden man behöver hantera:
1. Kortuppgifterna anges på ordersidan
2. Man öppnar ett hostat betalfönster
3. Man ansluter till en check-out sida där alla kundens uppgifter finnsTransaktionsflödet för olika växlar är idag ganska likartat, men de använder helt olika parameternamn och metod för att skicka parametrar (POST, GET, XML). Några har lite mer omfattande handskakning än andra.
Dock ser jag inga tekniska svårigheter att kunna implementera all nödvändig funktionalitet i ett applikationsprotokoll. Svårigheten ligger istället i att få alla att dels enas om att det är en bra idé (många kommer att hänvisa till säkerhet) och sedan att enas om en lösning som är tillräckligt flexibel att växa i.Ett möjligt första steg kan vara att sätta upp en gateway-tjänst som sköter konverteringen.
Mot transporttjänster borde det också vara möjligt att hitta ett gemensamt språk. Man har det ju på sätt och vis via Unifaun t.ex, du kan lätt byta från Posten till DHL … men du kan inte lika lätt byta från Unifaun till Apport.
När det gäller integration mot affärssystem så blir det lite mer komplicerat eftersom de kan ha olika struktur och strategier för hur olika typer av data läggs upp (options, varianter, strukturartiklar, kunder med flera kontaktpersoner och/eller adresser). Dessutom har de ju olika mycket data, så då uppstår frågan hur man skall hantera data som finns i det ena systemet men inte i det andra.
Men någon form av standardiserad webservice hade varit bra, med möjlighet att lägga till unika data för det aktuella systemet, men att hitta den optimala strukturen kan vara ganska svårt.Saken är väl bara den att det inte finns så stort intresse från de olika aktörerna att det skall vara lätt att byta system. Genom att det blir en del teknikkostnader förenade med ett byte av webshop och/eller betalväxel så sitter kunden lite mer fast.
Å andra sidan hade ett standard API gjort att ”alla stödjer alla” redan från början, och ingen behöver avstå från en viss webshop bara för att den inte stödjer den betalväxeln han vill använda.
Kodmyran : vi kommer nog från två olika perspektiv, jag älskar opensource, jobbar på universitetet, jag är van att utveckla för att förenkla, förbättra och för att dela med mig. Jag tänker ur perspektivet vad är enklast för alla. Jag ser detta något som opensource communityt kommer bygga fram (jag med andra) och de plattformar som väljer att följa systemet gör det.
Jag tolkar dig som ett företag som tänker vinster, arbetstimmar, investeringar. För er finns det ingen direkt vinst att utveckla detta, om ni inte heter google förståss, vilka gör allt opensource och tjänar hur mycket som helst ändå
@cande 17589 wrote:
Kodmyran : vi kommer nog från två olika perspektiv, jag älskar opensource, jobbar på universitetet….
Som samhällsmedborgare älskar jag modellen med våra universitet och att människor som är anställda kan forska och jobba fritt. Som företagare hatar jag när det sitter någon doktorand/ forskare eller professor och får full lön för 20 tim i veckan och sen kan driva ett företag vid sidan om utan att
1. Behöva lyfta lön
2. Betala för kontor
3. Investera i datorer, mobiltelefoner och allt annat.Vi sliter häcken av oss för att folk ska kunna gå på universitet och sen får man den här tillbaks: tunnelbanan borde vara gratis för studenter, vi vägrar betala, osolidariskt. Eller som nu, allt ska vara gratis och open-source.
Jag tycker att universiteten ska vara gratis, och med det menar jag att bara de som kan tänkas jobba utan lön ska få anställning. Det ska vara gratis för oss skattebetalare. Vi kan implementera en webbaserad utbildning som drivs av frivilliga, en open-source modell helt enkelt.
Okej, lite surgubbe över mig men imorgon på emeet ska jag vara gladare.
Edit: Jag vill bara påpeka att jag inte har något personligt mot någon och att universiteten ligger bakom många framgångsrika företag som gjort Sverige bättre på många sätt. (Då tänker jag inte på plastcykeln).
- Du måste vara inloggad för att svara på detta ämne.
