Home

Voor de nieuw site gaat er een hoop veranderen, tot aan frameworks en backends aan toe.
Zoiets resulteert ook in de noodzaak van een nieuwe API.

We gaan er vanuit dat het niet mogelijk is om de oude API tijdelijk naast de nieuwe te laten draaien, maar we zullen tijdig een beta versie van de API beschikbaar stellen zover dit verder gevorderd is.

Omdat het een dienst is voor jullie, developers, is het ook belangrijk dat jullie inspraak hebben.
Dit is een draft en kan ten allen tijden worden aangepast, zowel op ons initiatief als op basis van jullie feedback.

Deze API zal niet langer gebruik maken van in-url authenticatie (API key) maar zal worden vervangen door oAuth 2.0 (draft zoveel...).

De API opbouw zal ook flink omgegooid worden.
Allereerst zullen we de API versioned maken. Een api call zou kunnen zijn:

Code (php):

1
http://api.bierdopje.com/1/shows/info.json?showname=ncis

Hieruit kan je uitlezen:

Dat het API v1 is
Dat je de shows module aanspreekt
Dat je informatie op wil vragen
Dat je de output graag in JSON wenst (dit kan ook xml zijn, en in sommige gevallen wellicht atom, rss?)
Dat het serie "ncis" betreft. Dit zou bijv ook een show_id, tvdb_id, tvrage_id oid kunnen zijn.

De nieuwe API zal ratelimited zijn. Je kan dus niet meer onbeperkt tegen de API aan praten, 80.000 API calls op een dag voor Ã©Ã©n gebruiker zal er niet meer bij zijn. Limieten zullen enigszins coulant worden ingesteld, en kunnen we desgewenst per applicatie verhogen. Dat laatste zullen we natuurlijk alleen doen als we er 100% van op aan kunnen dat de developer er alles aan heeft gedaan om efficiÃ«nt met de API om te gaan.

Je krijgt in de return / headers van de return X-Ratelimit headers terug waarin je kan zien hoeveel je er nog over hebt. Op die manier kan je je applicatie bijv. in een zuinigere modus zetten.

Afijn, we dumpen de api keys en gaan over tot oAuth (zoals o.a. Twitter, Foursquare etc ook gebruiken).
Hiermee zal je dus afhankelijk zijn van een gebruiker namens wie je API calls gaat doen. Deze gebruiker zal de eerste keer goedkeuring moeten verlenen of applicatie X bepaalde acties namens zijn/haar account mag uitvoeren.

Een voordeel hiervan is dat de authenticatie grotendeels user-based is. Dit brengt een groot voordeel met zich mee: applicaties kunnen "schrijf" toegang krijgen om bepaalde zaken aan te passen. Hier valt aan te denken:

Wijzigen van WIP status voor wip 123456 / WIP voor aflevering 6, seizoen 3 van NCIS.
In favorieten plaatsen van Burn Notice
Ophalen favoriete series
Ophalen todo list van te kijken afleveringen
Als gekeken/verkregen/.... gezien markeren van een aflevering.

Vooralsnog zijn we niet van plan zaken als "bedankjes" te automatiseren, dit omdat dit de kracht hiervan wegneemt. Als applicaties ineens "ongemeende" bedankjes kunnen gaan plaatsen schiet niemand daar wat mee op.

De applicatie kan zowel read-only (enkel ophalen algemene / user specifieke gegevens) als read-write (ophalen + wegschrijven van bepaalde gegevens) werken. De gebruiker krijgt bij de vraag om toestemming de keus om dit toe te laten.

Om dit veiliger te laten verlopen zal dit ook betekenen dat applicatienamen uniek gaan worden.
Je kan hier ook een logo, beschrijving, link naar je website etc aan meegeven welke de gebruiker gaat zien.

Goed, dit was het even voor zover.
Nogmaals: dit is een draftversie en kan nog altijd veranderen.

Ik ben benieuwd naar jullie feedback, aanvullingen etc!

Geregistreerd: donderdag 11 december 2008 Berichten: 542

In deze draft zie ik een belangrijke stap voorwaarts op het vlak van API voor bierdopje.

Ik zal nog afwachten tot er meer duidelijkheid is welke soorten calls/examples er zullen zijn om feedback/aanvullingen te gegeven.

Geregistreerd: zaterdag 25 september 2010 Berichten: 504

Quote:

Dat je de output graag in JSON wenst (dit kan ook xml zijn, en in sommige gevallen wellicht atom, rss?)

Mijn voorkeur gaat uit naar xml, maar dit is een persoonlijke voorkeur. Waarom zou je eigenlijk via de API in RSS praten?

Quote:

De nieuwe API zal ratelimited zijn. Je kan dus niet meer onbeperkt tegen de API aan praten, 80.000 API calls op een dag voor Ã©Ã©n gebruiker zal er niet meer bij zijn. Limieten zullen enigszins coulant worden ingesteld, en kunnen we desgewenst per applicatie verhogen. Dat laatste zullen we natuurlijk alleen doen als we er 100% van op aan kunnen dat de developer er alles aan heeft gedaan om efficiÃ«nt met de API om te gaan.

Je krijgt in de return / headers van de return X-Ratelimit headers terug waarin je kan zien hoeveel je er nog over hebt. Op die manier kan je je applicatie bijv. in een zuinigere modus zetten.

Deze ratelimiter, gaat dit op basis van user of applicatie? Mag een applicatie max X calls doen? Of mag een user X calls doen?

Quote:

Afijn, we dumpen de api keys en gaan over tot oAuth (zoals o.a. Twitter, Foursquare etc ook gebruiken).
Hiermee zal je dus afhankelijk zijn van een gebruiker namens wie je API calls gaat doen. Deze gebruiker zal de eerste keer goedkeuring moeten verlenen of applicatie X bepaalde acties namens zijn/haar account mag uitvoeren.

Goeie verandering!

Quote:

Vooralsnog zijn we niet van plan zaken als "bedankjes" te automatiseren, dit omdat dit de kracht hiervan wegneemt. Als applicaties ineens "ongemeende" bedankjes kunnen gaan plaatsen schiet niemand daar wat mee op.

Ik zou dit heel anders willen benaderen. Ik wil niet geautomatiseerd bedankjes gaan sturen. Stel je download een subtitle met AutoSub, ik wil op die subtitle kunnen klikken en een bedankje typen. Als ik nu zou willen bedanken zou ik naar de website van bierdopje moeten gaan inloggen aflevering opzoeken, bedankje typen. Als dit nou ook via de API zou kunnen zou geweldig zijn!

Het gaat er bij mij dus niet om dat automatisch bedankje stuurt, eerder dat je vanuit applicaties ook bedankjes kan sturen.

Quote:

Om dit veiliger te laten verlopen zal dit ook betekenen dat applicatienamen uniek gaan worden.
Je kan hier ook een logo, beschrijving, link naar je website etc aan meegeven welke de gebruiker gaat zien.

Unieke naam? Je hebt bij OAuth een sleutel van de applicatie, op die manier kan je zeker weten dat het van die applicatie afkomt. Deze sleutel kan ook bij opensource projecten verborgen meeleveren. Op die manier weet je zeker dat je toegang geeft alleen aan die applicatie. Wel is het aan te raden om voor dit authentizeren HTTPS te ondersteunen, anders kan je de develsleutel als nog meelezen.

Quote:

Ik ben benieuwd naar jullie feedback, aanvullingen etc!

Net als @lodder ben ik geintereseerd in welke calls er beschikbaar komen.

Geregistreerd: zaterdag 25 september 2010 Berichten: 504

Trouwens over OAuth:
http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars/

Bevat veel informatie over oauth

Over hoeveel tijd pratne we eigenlijk voordat dit allemaal uitkomt?

Schitterend, ik kan niet wachten om hiermee aan de slag te gaan.

Vooral de "write" mogelijkheden zullen een goede verbetering zijn.

Ik vraag me net als zyronix af of die rate limiet user gebaseerd zal zijn of applicatie gebaseerd.

Een api call die ik wel zou willen is om de laatste x aantal nieuwe ondertitels (eng/nl) van een bepaalde gebruiker zijn favorieten te krijgen. Hiervoor gebruik ik nu de RSS om alle subs af te halen en dan te kijken per sub of de show in zijn favorieten zit. Het was gemakkelijker op een gebruikerid mee te geven en een variabele x en zo de laatste subs voor die gebruiker terug te krijgen.

Geregistreerd: zaterdag 25 september 2010 Berichten: 504

Quote:

Een api call die ik wel zou willen is om de laatste x aantal nieuwe ondertitels (eng/nl) van een bepaalde gebruiker zijn favorieten te krijgen. Hiervoor gebruik ik nu de RSS om alle subs af te halen en dan te kijken per sub of de show in zijn favorieten zit. Het was gemakkelijker op een gebruikerid mee te geven en een variabele x en zo de laatste subs voor die gebruiker terug te krijgen.

Dit zou je natuurlijk zelf kunnen programmeren, als de favorieten geschikbaar worden via de API.
Dat haal je deze favorieten shows op, ga je bij de shows kijken of er nieuwe afleveringen zijn (airdate variable). Dit is denk ik beter omdat je namelijk niet allerlei van dit soort 'kleine' features wilt hebben.

Quote:

lodder schreef op dinsdag 03 april 2012 @ 10:51:
In deze draft zie ik een belangrijke stap voorwaarts op het vlak van API voor bierdopje.
Ik zal nog afwachten tot er meer duidelijkheid is welke soorten calls/examples er zullen zijn om feedback/aanvullingen te gegeven.

Sowieso in grote lijnen die we al hebben, met extra calls. Wellicht gaan er een paar uit de huidige sneuvelen omdat deze veelal "wrappers" zijn voor andere calls.

Quote:

Mijn voorkeur gaat uit naar xml, maar dit is een persoonlijke voorkeur. Waarom zou je eigenlijk via de API in RSS praten?

Vraag me dan toch echt af waarom. XML is "vies" en heeft een flinke overhead. Als we JSON gingen verplichten zou dat op termijn een hoop bandbreedte (en kopzorgen

) kunnen besparen

Waarom RSS: Nou in principe kunnen we de data naar elk gewenst formaat export-filteren.

Quote:

Deze ratelimiter, gaat dit op basis van user of applicatie? Mag een applicatie max X calls doen? Of mag een user X calls doen?

Dat is nog niet besloten maar ik zie 2 opties:

Per applicatie-gebruiker combinatie
Per gebruiker

Dat laatste is natuurlijk wat eenvoudiger bij te houden en minder makkelijk te omzeilen zeg maar

Daarnaast zie ik niet in waarom je meerdere apps zou moeten hebben die allebei veelvuldig API calls aan het doen zijn

Maar goed, kan alle kanten op nog.

Quote:

Ik zou dit heel anders willen benaderen. Ik wil niet geautomatiseerd bedankjes gaan sturen. Stel je download een subtitle met AutoSub, ik wil op die subtitle kunnen klikken en een bedankje typen. Als ik nu zou willen bedanken zou ik naar de website van bierdopje moeten gaan inloggen aflevering opzoeken, bedankje typen. Als dit nou ook via de API zou kunnen zou geweldig zijn!
Het gaat er bij mij dus niet om dat automatisch bedankje stuurt, eerder dat je vanuit applicaties ook bedankjes kan sturen.

Het probleem is dat je dan in principe ook je applicatie automatisch, zonder tussenkomst van de eindgebruiker, ongemeende bedankjes de wereld in kan schieten. Wat de applicatie kan, kan het ongetwijfeld ook unattended.

Of we moeten daar weer een extra bevestiging server-side voor vereisen, maar dat is wat veel gedoe.

Het zou feitelijk hetzelfde zijn als het forum, welke ook niet via de API beschikbaar zal zijn.

Quote:

Unieke naam? Je hebt bij OAuth een sleutel van de applicatie, op die manier kan je zeker weten dat het van die applicatie afkomt. Deze sleutel kan ook bij opensource projecten verborgen meeleveren. Op die manier weet je zeker dat je toegang geeft alleen aan die applicatie.

Het gaat meer om de duidelijkheid naar de eindgebruiker. Stel dat we een eigen applicatie uit gaan geven, en die 'Bierdopje.com Live' gaan noemen. Kan jij vervolgens - in theorie - diezelfde naam pakken, de gebruiker ziet He! dat is de officiele app dus die accepteer ik. Vervolgens kan jij met je app weer "foute" dingen gaan doen

Tuurlijk dat kunnen we afvangen door er een tagje 'official app' aan vast te knopen of 'verified app' maar dat is ook weer zoveel gedoe. Als we de appname een index maken zou dat dit probleem voorkomen.

Quote:

Wel is het aan te raden om voor dit authentizeren HTTPS te ondersteunen, anders kan je de develsleutel als nog meelezen.

Ik weet niet in hoeverre dit gaat gebeuren. We doen geen bankzaken oid, dus om het enkel te versleutelen omwille van die key is dat wat prijzig (qua resources want SSL kost CPU, maar ook financieel aangezien we dan per webserver een extra IP nodig hebben

)

Quote:

zyronix schreef op dinsdag 03 april 2012 @ 12:14:
Trouwens over OAuth:
http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars/
Bevat veel informatie over oauth
Over hoeveel tijd pratne we eigenlijk voordat dit allemaal uitkomt?

Mooi artikel, heb die even tussendoor doorgenomen.
Moeten we dus NIET de Twitter-approach nemen (wel qua app registratie) maar de Google of (ugh) Facebook mbt de consumer secrets.
Gaat het nog leuker maken, er zijn nu al vrij weinig oAuth provider classes beschikbaar dus maakt dat er niet makkelijker op vrees ik. Gaat sowieso wel oAuth 2.0 worden natuurlijk

Zo, weer even creatief geknipt en geplakt met die quotes

Geregistreerd: zaterdag 25 september 2010 Berichten: 504

Quote:

Dat is nog niet besloten maar ik zie 2 opties:
Per applicatie-gebruiker combinatie
Per gebruiker

Dat laatste is natuurlijk wat eenvoudiger bij te houden en minder makkelijk te omzeilen zeg maar Daarnaast zie ik niet in waarom je meerdere apps zou moeten hebben die allebei veelvuldig API calls aan het doen zijn Maar goed, kan alle kanten op nog.

net als in het autosub topic vraag ik me af wat je precies bedoelt met rate limiter? Snelheid limiteren (max 50 kb/s)? Of calls limiteren (50 calls per dag?)? En aan wat voor een hoeveelheid loop je te denken?
Ik ben voor gebruiker en niet gebruiker / app, een veel schonere oplossing ^^

Quote:

Het probleem is dat je dan in principe ook je applicatie automatisch, zonder tussenkomst van de eindgebruiker, ongemeende bedankjes de wereld in kan schieten. Wat de applicatie kan, kan het ongetwijfeld ook unattended.

Als je een spamfilter in bouwt voorkom je dit

Want als het automatisch gaat, is de kans groot dat bedankjes steeds het zelfde. Of je stelt dit in als regel voor de API, als mensen het toch doen disable je de OAUTH sleutel.

Ik wil graag bedankjes doen, maar vind het nu gewoon te omslachtig om het te doen.

Quote:

Tuurlijk dat kunnen we afvangen door er een tagje 'official app' aan vast te knopen of 'verified app' maar dat is ook weer zoveel gedoe. Als we de appname een index maken zou dat dit probleem voorkomen.

Ik vind het aangeven dat een applicatied verified is eigenlijk wel een goed idee, dan kan je zien of andere gebruikers positief reageren op een applicatie en dat het geen applicatie is die heel buggy is. Met verified bedoel ik dat de applicatie goedgekeurd is door jullie, dat ie voldoet aan alle richtlijnen. Verified apps hebben dan een minder limiet op calls ofzo. En niet verified apps kunnen maar 5000 calls per dag doen ofzo.
(tis maar een ideetje

)

Quote:

Ik weet niet in hoeverre dit gaat gebeuren. We doen geen bankzaken oid, dus om het enkel te versleutelen omwille van die key is dat wat prijzig (qua resources want SSL kost CPU, maar ook financieel aangezien we dan per webserver een extra IP nodig hebben )

Twitter bevat toch ook geen bank zaken en heeft toch https? Veel gebruiker gebruiken het zelfde wachtwoord voor mail, bierdopje, webshops etc... En waarom heb je een extra IP adres nodig? https kan je gewoon aan port 443 binden op het zelfde IP adres. Het certificaat kan je ook zelf maken, maak je eigen bierdopje CA aan. Als mensen een OAUTH registeren kunnen ze ook het server certificaat + ca certificaat downloaden om te checken. De verantwoordelijkheid ligt dan bij de applicatie ontwikkelaar.

Quote:

Zo, weer even creatief geknipt en geplakt met die quotes

Een knutselwerk van een kleuter is er niks bij! :*)

Quote:

net als in het autosub topic vraag ik me af wat je precies bedoelt met rate limiter? Snelheid limiteren (max 50 kb/s)? Of calls limiteren (50 calls per dag?)? En aan wat voor een hoeveelheid loop je te denken?

Nee, gaat om dat men maximaal X requests kan doen. Trucs om buiten die X requests de boel te gaan vertragen zodat het blijft werken zou kunnen, maar heeft niet de voorkeur. Dat zou dan sowieso veel minder dan 50 kb/s worden, denk eerder aan 1.

Quote:

Ik ben voor gebruiker en niet gebruiker / app, een veel schonere oplossing ^^

Is iets simpeler in te bouwen, maar als iemand wel weer meerdere programma's door elkaar gebruikt kan die snel tegen een limiet aanlopen. Maar daar zijn ook wel weer oplossingen voor de vinden, Premium members krijgen meer API calls bijv.

Quote:

Als je een spamfilter in bouwt voorkom je dit Want als het automatisch gaat, is de kans groot dat bedankjes steeds het zelfde. Of je stelt dit in als regel voor de API, als mensen het toch doen disable je de OAUTH sleutel.

Zou kunnen, maar

Quote:

Ik wil graag bedankjes doen, maar vind het nu gewoon te omslachtig om het te doen.

Dat is nu sowieso "verboden", alle andere communicatie dan via de API mag niet

Geen HTML scraping of remote form posting dus.

Quote:

Ik vind het aangeven dat een applicatied verified is eigenlijk wel een goed idee, dan kan je zien of andere gebruikers positief reageren op een applicatie en dat het geen applicatie is die heel buggy is. Met verified bedoel ik dat de applicatie goedgekeurd is door jullie, dat ie voldoet aan alle richtlijnen. Verified apps hebben dan een minder limiet op calls ofzo. En niet verified apps kunnen maar 5000 calls per dag doen ofzo.
(tis maar een ideetje )

Hmm dat klinkt op zich wel goed, maar dan blijft de unieke naam sowieso bestaan want anders kan men een "not verified" app gaan zitten faken

Quote:

Twitter bevat toch ook geen bank zaken en heeft toch https? Veel gebruiker gebruiken het zelfde wachtwoord voor mail, bierdopje, webshops etc... En waarom heb je een extra IP adres nodig? https kan je gewoon aan port 443 binden op het zelfde IP adres. Het certificaat kan je ook zelf maken, maak je eigen bierdopje CA aan. Als mensen een OAUTH registeren kunnen ze ook het server certificaat + ca certificaat downloaden om te checken. De verantwoordelijkheid ligt dan bij de applicatie ontwikkelaar.

Je kan maar Ã©Ã©n SSL site per IP draaien, tenzij je SNI gaat gebruiken maar als je gebruikte applicatie/library/browser dat niet snapt ben je de klos want dan krijgt men enkel de Ã©Ã©rste site te zien. Als we het doen, doen we het goed en niet halfbakken met self-signed certificaten maar gewoon met een (wildcard) certificate.

Er gaat straks meer dan Ã©Ã©n SSL site draaien, want ook de login moet over SSL lopen.
Dan heb je er dus al 2, en hebben we dus 2 "schone" IP's nodig. Maar dan spreek je over een euro per IP (gaat ongetwijfeld (fors) omhoog straks) per maand dus niet echt een ramp.

[/quote]
Een knutselwerk van een kleuter is er niks bij! :*)

[/quote]
Arg, en nu weer

Geregistreerd: zondag 26 september 2010 Berichten: 32

Hi, kan iemand me vertellen waar ik docs voor API v2 vinden kan? Of is dit een "work in progress" dat via deze discussie topic besproken word?

Greetings,
Michael

Er zijn nog geen docs, dit is nu een designfase waarin we input van onze API gebruikers willen verzamelen.

Geregistreerd: zaterdag 29 november 2008 Berichten: 1511

Wat de bedankjes betreft..
Als je toch een API ondersteund die wel toelaat zonder enig probleem subs te downloaden zie ik niet in waarom bedankjes hierin niet zouden meekunnen.
De discussie aantal downloads versus aantal bedankjes hebben we al meermaals gevoerd.
Enerzijds zeggen we dat het aantal dl's al voldoende zou moeten zijn als bewijs van dank.
Anderzijds is het altijd leuk een bedankje te krijgen.
Indien je het niet voorziet vrees ik dat velen zoals nu een sub dl'er gaan gebruiken en sowieso geen bedankjes meer gaan sturen. Door mede goeie subdl'ers en programmeurs zie ik sowieso dat meer en meer mensen een subdl'er gebruiken.
Tenslotte ik gebruik om te bedanken altijd 'thnx' of iets dergelijks. Als dit nu geautomatiseerd is of niet. Hoe gaat men het verschil uitmaken.
Een optie zou misschien kunnen zijn - en dit is denk ik vrij simpel - dat geautomatiseerd bedanken kan maar dat dan automatisch in het bedankje zelf staat bv. "gepost via subdl'r X" Dan weet de poster van de de sub die de bedankjes leest direct dat het al dan niet om een geautomatiseerd bericht gaat. Wat volgens mij niets teniet doet aan de waarde. Integendeel. Dan gaat men pas echt zien hoeveel er gedownload wordt. Aantal dl's + bedankjes (al dan niet geautomatiseerd. Nu wordt er volgens mij veel meer gedownload dan op site verschijnt. Of toont de dl'meter aantal gedownload ook de downloads via API?
Is uiteraard mijn visie..

Seba28 wijzigde dit bericht op 26-04-2012 om 18:56, totaal 1 keer bewerkt

Geregistreerd: donderdag 15 mei 2008 Berichten: 152

Quote:

Seba28 schreef op donderdag 26 april 2012 @ 20:55:
Wat de bedankjes betreft..
Als je toch een API ondersteund die wel toelaat zonder enig probleem subs te downloaden zie ik niet in waarom bedankjes hierin niet zouden meekunnen.
De discussie aantal downloads versus aantal bedankjes hebben we al meermaals gevoerd.
Enerzijds zeggen we dat het aantal dl's al voldoende zou moeten zijn als bewijs van dank.
Anderzijds is het altijd leuk een bedankje te krijgen.
Indien je het niet voorziet vrees ik dat velen zoals nu een sub dl'er gaan gebruiken en sowieso geen bedankjes meer gaan sturen. Door mede goeie subdl'ers en programmeurs zie ik sowieso dat meer en meer mensen een subdl'er gebruiken.
Tenslotte ik gebruik om te bedanken altijd 'thnx' of iets dergelijks. Als dit nu geautomatiseerd is of niet. Hoe gaat men het verschil uitmaken.
Een optie zou misschien kunnen zijn - en dit is denk ik vrij simpel - dat geautomatiseerd bedanken kan maar dat dan automatisch in het bedankje zelf staat bv. "gepost via subdl'r X" Dan weet de poster van de de sub die de bedankjes leest direct dat het al dan niet om een geautomatiseerd bericht gaat. Wat volgens mij niets teniet doet aan de waarde. Integendeel. Dan gaat men pas echt zien hoeveel er gedownload wordt. Aantal dl's + bedankjes (al dan niet geautomatiseerd. Nu wordt er volgens mij veel meer gedownload dan op site verschijnt. Of toont de dl'meter aantal gedownload ook de downloads via API?
Is uiteraard mijn visie..

Niet mee eens.
Wanneer een bedankje automatisch gaat is de hele waarde ervan af en wordt het even waardevol als het aantal downloads, waardoor je dan beter 1 van de 2 weg kan laten.
Een bedankje heeft vÃ©Ã©l meer waarde persoonlijk dan automatisch.

Gewoon zo laten

Volgens mij telt de downloadmeter ook de downloads met API mee

Geregistreerd: zaterdag 22 maart 2008 Berichten: 577

Misschien een onderscheid maken tussen bedankjes van op bierdopje.com en van third party applicaties. Als je dan kijkt naar de bedankjes, zie je ergens staan "2345 gebruikers bedankten de *uploader van de sub* voor zijn zijn ondertitel via een third party applicatie." oid natuurlijk .

Een beetje zoals een (facebook) like-knop eigenlijk (maar dan met een andere naam )

---

Voor de rest ben ik al blij als ik via de API kan laten weten welke afleveringen ik gezien heb.

Geregistreerd: zaterdag 29 november 2008 Berichten: 1511

Quote:

Niet mee eens.
Wanneer een bedankje automatisch gaat is de hele waarde ervan af en wordt het even waardevol als het aantal downloads, waardoor je dan beter 1 van de 2 weg kan laten.
Een bedankje heeft vÃ©Ã©l meer waarde persoonlijk dan automatisch.

Gewoon zo laten

Ben ik wel mee eens maar gezien het groeiend aantal 'goeie' sub dl'ers vrees ik dat het bedankjes systeem teniet zal gaan. Waarom de moeite doen wanneer men gewoon op een knop moet duwen voor zijn subs te dl'n. Of in vele gevallen zelfs niet meer moet klikken en het automatisch gebeurt. Dan zou ik persoonlijk als vertaler toch nog liever zien dat mijn sub werkelijk door een 3rd party is gedl't en bedankt werd.
Enfin we kunnen dit simpel houden.. Misschien dat men een poll kan houden als volgt.
Willen vertalers een bedankje zien ook als hij is geautomatiseerd.
Ja. Graag.
Nee met risico dat er gewoon geen bedanking komt.

Zoals ik het nu zie evolueren we toch naar een bedankloos systeem. Ik zie dit aan de huidige bedankjes en eerlijk gezegd aan mezelf. Ja, ik wij gerust ook de vinger naar mezelf. Ik ben vertaler maar sinds ik jbiersubdl'r gebruik bedankt ik enkel nog als ik er specifiek aan denk en wat meer tijd heb om BD even af te schuimen. Laat men de keuze geven aan de vertalers.. Een poll kan soelaas brengen.

Geregistreerd: zondag 26 september 2010 Berichten: 32

Hi Sypher,

OK, dank je, dacht dat ik de link op de 1 of andere manier gemist had... :-)

Ik zie dat een hoop mensen meepraten, dat doet me deugt. Mijn "2 cents":

- Laat alles over https lopen, in de praktijk levert http alleen teveel problemen op
- Kodeer het versienummer expliciet, d.i. v1 ipv 1
- Neem het formaat van de output NIET op in je REST eindpunt, laat de client deze vragen via de http header, op deze manier kun je transparent andere formaten toevoegen, b.v. xml of yaml
- Wat bij mij in de praktijk altijd goed werkt is een prototype bouwen met alleen de REST eindpunten die je met online tools kunt checken op fouten in de "werkwoorden" en de bijbehorende URL struktuur

Greetings,
Michael

Quote:

- Laat alles over https lopen, in de praktijk levert http alleen teveel problemen op

HTTPS levert overhead, een hogere systeemload en in principe hogere maandlasten met zich mee. Aangezien de user authenticatie via een ander (wel SSL-secured systeem zal verlopen is dat voor de API wellicht overkill.

Quote:

- Kodeer het versienummer expliciet, d.i. v1 ipv 1

Lijkt me geen probleem

Quote:

- Neem het formaat van de output NIET op in je REST eindpunt, laat de client deze vragen via de http header, op deze manier kun je transparent andere formaten toevoegen, b.v. xml of yaml

Dat kan toch al, voegen we yaml toe dan is het info.yaml

Ik ken zo 123 geen nette api's die dat op die manier doet, jij?

Quote:

- Wat bij mij in de praktijk altijd goed werkt is een prototype bouwen met alleen de REST eindpunten die je met online tools kunt checken op fouten in de "werkwoorden" en de bijbehorende URL struktuur

Die snap ik even niet, heb je een voorbeeld?

Sypher wijzigde dit bericht op 27-04-2012 om 19:14, totaal 1 keer bewerkt

Geregistreerd: zondag 26 september 2010 Berichten: 32

Hallo Sypher,

wat betreft https: de overhead is maar een paar procent in de praktijk, hogere maandlasten klopt... Persoonlijk zou ik de paar euro investeren voor een zekere verbinding, maar dat moet iedereen zelf beslissen :-)

Wat betreft het formaat in het eindpunt: Dit is een discussie die sterk leeft in de API wereld, maar wat ik lees is dat de meesten er langzaam van weg gaan. Nadeel van het output formaat coderen in je URL is dat de clients bij een nieuw formaat een nieuwe URL moeten "leren" te handeln. Bij een gelijk blijven eindpunt, dus bijv. altijdhttp://api.bierdopje.com/v1/shows/info?showname=ncis hoef je je URL handling niet te veranderen. De client kan met de header aanvragen JSON, XML of YAML, en via een if then elif of case statement het antwoord uit elkaar nemen en dan in zijn interne formaat omzetten, maakt het voor de client makkelijker. Zie bijv.http://weblog.mattdorn.com/content/restful-web-apps-with-django-piston-and-ext-js/

Wat betreft de rest eindpunten en online tool. Bouw een minimale applicatie met de gedachte eindpunten die bijvoorbeeld altijd "42" terugggeven en speel het geheel eens door (use-cases) met een online tool zoals bijvoorbeeldhttp://resttesttest.com/ en kijk of alles "goed voelt" :-)

Greetings,
Michael

Geregistreerd: woensdag 04 juli 2007 Berichten: 799

In welke fase van ontwikkeling zit de API 2.0?

-- Sayoki

Quote:

Sayoki schreef op vrijdag 04 januari 2013 @ 11:11:
In welke fase van ontwikkeling zit de API 2.0?

In de plan fase.
Hij kan sowieso niet eerder komen dan de (public) beta van v3.

Geregistreerd: zaterdag 29 november 2008 Berichten: 1511

En wanneer komt de public beta van v3 ?

Geregistreerd: dinsdag 16 augustus 2011 Berichten: 2

Is hier nog iets nieuws over te melden?

Oh, ja we hadden dit topic ook nog.

Toch gaan we hier verder:
Discussietopic: Bierdopje API 3.0

Home

BierdopjeV3 Alpha nu beschikbaar. Wil je helpen? Kijk dan hier

API 2.0 discussie topic