Varför har ni inte byggt in en inlogging med i APIn?
Blir mycket lättare för alla att använda applikationen då med ju eller hur?
API Nackdel
Current thread - API Nackdel
Nu hänger jag inte med riktigt, menar du att man ska logga in i uppladdaren? Meningen är att den ska skicka kakor från din befintliga inloggning.
Jagkanske är ute och cyklar, men..
Jagkanske är ute och cyklar, men..
Hur gör man om man vill göra en klient som inte går via webbläsaren? Enda sättet nu är att använda cookien på något sätt?
Tänk om man vill göra en uppladdare för en mobil? Då vill man gärna mata in användarnamn och lösenord i sitt program för att logga in. Nu är detta ju inte möjligt!
Tänk om man vill göra en uppladdare för en mobil? Då vill man gärna mata in användarnamn och lösenord i sitt program för att logga in. Nu är detta ju inte möjligt!
vi kommer nog kika vidare på det lite senare, just nu räcker det här för tävlingen då bidraget ska bäddas in på sidan.
Det som iofs vore kul att veta är om folk har några speciella önskemål på åtkomst till api:t; soap, vanlig http-request, eller nån annan lösning
Det som iofs vore kul att veta är om folk har några speciella önskemål på åtkomst till api:t; soap, vanlig http-request, eller nån annan lösning
Man borde kunna skicka med inloggningsuppgifter med API:n så att man kan göra till mobil etc.
Öppna standarder är kärlek. Mer sådant uppmuntras!
Jo jag kommer kika på det här nån gång, vet inte när dock.n
nDet som skulle vara kul och veta från folk:nVad skulle den konkreta vinsten vara att tillhandahålla webservice via SOAP / XML-RPC?
nDet som skulle vara kul och veta från folk:nVad skulle den konkreta vinsten vara att tillhandahålla webservice via SOAP / XML-RPC?
Flera upladdade bilder, kanske?
Har du nånsin använt webbläsaren Flock?
Den kan ladda upp blogginlägg direkt genom en knapp i verktygsfältet, bygger på Firefox, och finns för både Linux, Mac och Windows, men stödjer inte egna POST-Requests, vilket man behöver använda för att ladda upp bilder via den nuvarande APIn. Den stödjer både Wordpress("Self-hosted" och via Wordpress.com, alla versionerna), Facebook, Youtube, Typepad, Blogger och ett tiotal till :-)
Dessutom skulle det isåfall vara enklare att integrera sin egen sajt med BDB; Facebook och liknande grejer har redan gjort så.
För tillfället är Totiki den enda tjänsten(som jag känner till) som integrerar BDB med nånting alls, och den sajten gör det inte så bra ens.
Den kan ladda upp blogginlägg direkt genom en knapp i verktygsfältet, bygger på Firefox, och finns för både Linux, Mac och Windows, men stödjer inte egna POST-Requests, vilket man behöver använda för att ladda upp bilder via den nuvarande APIn. Den stödjer både Wordpress("Self-hosted" och via Wordpress.com, alla versionerna), Facebook, Youtube, Typepad, Blogger och ett tiotal till :-)
Dessutom skulle det isåfall vara enklare att integrera sin egen sajt med BDB; Facebook och liknande grejer har redan gjort så.
För tillfället är Totiki den enda tjänsten(som jag känner till) som integrerar BDB med nånting alls, och den sajten gör det inte så bra ens.
Du kan ha tillgång till sidan via fler kanaler. Hur jota dum får man vara? Allt mäts inte i pengar och det är trist att se att bdb har gått och blivit så pengahungriga på sistonne. Men vill du ha en konkret vinst i det hela kan du ju kombinera reklam + uppladdare. Du får dessutom utökande av varumärket.
Jag troooooor han menade konkret vinst mer i betydelsen "Vad kan det faktiskt användas till och kommer folk faktiskt göra nåt av det?" Bilddagboken har väl inte precis den publik som tycker det är användbart att ladda upp bilder från andra hemsidor, även om en eller två använder Flock.
Men det man kan få ut är ju ungefär att man kan använda bilddagboken på andra sätt än i en modern webbläsare på en fullskalig dator, om någon faktiskt bryr sig om att bygga sådana tjänster...
Men det man kan få ut är ju ungefär att man kan använda bilddagboken på andra sätt än i en modern webbläsare på en fullskalig dator, om någon faktiskt bryr sig om att bygga sådana tjänster...
Nuvarande API:ts brist är väl framförallt att det inte är så mycket till API. Bytte man bara URL till bilddagboken.se/images/, tog bort "action"-parametern och accepterade typ HTTP-Auth skulle det ju vara (snålt implementerad) REST?
Jag kan personligen tycka att typ XML-RPC, SOAP blah blah verkar överflödiga när HTTP klarar det mesta utan någon extra abstraktion. REST har sina brister och OAuth har sina användningsområden, men.
Ändrat 2009-06-10 21:15
Ändrat 2009-06-10 21:17
Jag kan personligen tycka att typ XML-RPC, SOAP blah blah verkar överflödiga när HTTP klarar det mesta utan någon extra abstraktion. REST har sina brister och OAuth har sina användningsområden, men.
Ändrat 2009-06-10 21:15
Ändrat 2009-06-10 21:17
Jo som sagt, ska piffa upp api-delen någongång när tid ges (ska pusha på det).
Men till frågan XML-RPC, SOAP eller REST. Jag personligen skulle nog falla in på XML-RPC här, även fast det inte "stöds" av w3c. XML-RPC är förvisso patenterat, och jag har inte grottat in mig djupare på hur det påverkar något, men det är ju rätt välanvänt så det känns riskfritt.
SOAP ligger ju på W3C och känns kanske lite tryggare av den anledningen, men samtidigt är det ju lite mer invecklat än XML-RPC och den funktionalitet på Bilddagboken som är intressant att exponera i ett API är ju inte direkt avancerad.
REST har ju också sin charm med enkelheten. Däremot har jag lite dålig koll på hur det ställer sig mot färdiga lib som finns till SOAP/XML-RPC för olika språk?
Men till frågan XML-RPC, SOAP eller REST. Jag personligen skulle nog falla in på XML-RPC här, även fast det inte "stöds" av w3c. XML-RPC är förvisso patenterat, och jag har inte grottat in mig djupare på hur det påverkar något, men det är ju rätt välanvänt så det känns riskfritt.
SOAP ligger ju på W3C och känns kanske lite tryggare av den anledningen, men samtidigt är det ju lite mer invecklat än XML-RPC och den funktionalitet på Bilddagboken som är intressant att exponera i ett API är ju inte direkt avancerad.
REST har ju också sin charm med enkelheten. Däremot har jag lite dålig koll på hur det ställer sig mot färdiga lib som finns till SOAP/XML-RPC för olika språk?
välanvänt, men dess "dokumentation" ger en mardrömmar...
ni skulle ju ochså kunna bara implementera allihop, så det fanns olika filer som tybbilddagboken.se/xmlrpc.php,bilddagboken.se/soap.php o.s.v., så skulle man kunna välja vilken man ville använda :)
ni skulle ju ochså kunna bara implementera allihop, så det fanns olika filer som tybbilddagboken.se/xmlrpc.php,bilddagboken.se/soap.php o.s.v., så skulle man kunna välja vilken man ville använda :)
Det behövs ju inga libs för REST utöver HTTP (och JSON- eller XML-parsers för data). Enkelt!
Ja exakt, REST är enkelt i jämförelse med t.ex. SOAP i specifikationen. Men t.ex. php har ju inbyggda (tror de är standard?) SOAP-lib som gör det väldigt lätt att använda även SOAP. Det var lite mer det jag tänkte på, om REST är så mycket enklare att använda än SOAP om man tar hänsyn till dylika lib.