Saknar du API'er? Är någon API trasig? Skriv här!

[PerA]

http://wiki.turfgame.com/sv/wiki/TurfAPI_V3

v3 släppt
en del uppdateringar.
blocktid, revisits, date_taken, etc.

Ni har inga planer på att följa det här förslaget? Det är som sagt ett väldigt underligt sätt att använda xml.

* Om man begär en användare skulle zoner gärna kunna vara egna XML-barn till user-elementet. Då kan man få med metadata om zonerna i samma förfrågan. Konkatenerade strängar av id-nummer känns mycket underligt i ett XML-dokument. Detsamma gäller medaljer.

[Drassen]

det skulle vi kunna fixa till nästa version, men metadatan kommer dock vara lite begränsad pga. servrar och belastning. (ni har väl donerat)

[GuteLappen]

(ni har väl donerat)

Självklart. Lite OT kanske, men eftersom du tar upp donering föreslår jag att man kan ha flera donerings medaljer.
Sätt årtal på de medaljer som finns så är chanserna större att ni får in mer pengar.

Skickat från min GT-I9305N via Tapatalk 2

[whiterocker]

http://wiki.turfgame.com/sv/wiki/TurfAPI_V3

v3 släppt
en del uppdateringar.
blocktid, revisits, date_taken, etc.

Noden blocked_seconds returneras enbart ifall en zon är blockerad detta kommer generera felmeddelanden eftersom apparna kommer i de flesta fall inte hitta den noden.

Det vore bra ifall blocked_seconds kunde returnera -1 eller 0 ifall en zon inte är blockerad.

[AJ_]

Noden blocked_seconds returneras enbart ifall en zon är blockerad detta kommer generera felmeddelanden eftersom apparna kommer i de flesta fall inte hitta den noden.

Det vore bra ifall blocked_seconds kunde returnera -1 eller 0 ifall en zon inte är blockerad.

Det håller jag inte med om. Att alltid skriva ut allt tänkbart data även då det inte existerar är enbart slöseri med bandbredd. Det är upp till den som läser API:et att använda en vettig XML-parser och hantera saknat data. Däremot är det bra om dokumentationen är tydlig med vilka fält som alltid kan förväntas existera och vilka som är optional.

[AJ_]

Angående formatering av @zones i <user>:

det skulle vi kunna fixa till nästa version, men metadatan kommer dock vara lite begränsad pga. servrar och belastning. (ni har väl donerat)

Till en början är det bara en ren formateringsfråga, om man själv behöver splitta strängen på komma(,) eller få det gratis från XML-parsern. Samma sak gäller naturligtvis medal-attributet.

Code: Select all

<user id=".." name="..." ... >

  <zones>

    <zone id=".."/>

    <zone id=".."/>

    <zone id=".."/>

  </zones>

  <medals>

    <medal id=".."/>

    <medal id=".."/>

  </medals>

</user>

I nästa steg kan man lägga till fler attribut på <zone/>, men det är som du säger en avvägning mellan prestanda och informationsmängd. Till stor del beror det också på vad användarna av API:et kommer göra. Det skulle kunna vara en prestandavinst att lägga in all information i första steget redan när användaren hämtas, för att slippa fler requests till servern om zon-infon ändå alltid ska hämtas. Men å tredje sidan beror det också på var saker kan cacheas.

Jag noterar att ID fortfarande saknas bland <zone>-attributen, vilket gör det svårare att gå från
http://api.turfgame.com/v3/zones till http://api.turfgame.com/v3/zones/id:3002 Det går att gå via namnet, men det ser jag som en onödig felkälla med tanke på teckenkodningar och att namnen ändrar på sig.
Se http://issues.turfgame.com/view/115

Jag kommer också snart att rapportera en bugg angående "Content-Type"-headern som nu är text/html, den borde nog vara "text/xml" eller något annat som talar om att det handlar om XML.

[UrbanGeeks]

Noden blocked_seconds returneras enbart ifall en zon är blockerad detta kommer generera felmeddelanden eftersom apparna kommer i de flesta fall inte hitta den noden.

Det vore bra ifall blocked_seconds kunde returnera -1 eller 0 ifall en zon inte är blockerad.

Det håller jag inte med om. Att alltid skriva ut allt tänkbart data även då det inte existerar är enbart slöseri med bandbredd. Det är upp till den som läser API:et att använda en vettig XML-parser och hantera saknat data. Däremot är det bra om dokumentationen är tydlig med vilka fält som alltid kan förväntas existera och vilka som är optional.

+1 på det, vet man vad som ibland utelämnas är det inga problem.

[TBIT]

Lika bra att byta till JSON om man vill spara datatrafik, och även slippa använda några CPU-cykler...

[UrbanGeeks]

Angående formatering av @zones i <user>:

det skulle vi kunna fixa till nästa version, men metadatan kommer dock vara lite begränsad pga. servrar och belastning. (ni har väl donerat)

Till en början är det bara en ren formateringsfråga, om man själv behöver splitta strängen på komma(,) eller få det gratis från XML-parsern. Samma sak gäller naturligtvis medal-attributet.

Code: Select all

<user id=".." name="..." ... >

  <zones>

    <zone id=".."/>

    <zone id=".."/>

    <zone id=".."/>

  </zones>

  <medals>

    <medal id=".."/>

    <medal id=".."/>

  </medals>

</user>

I nästa steg kan man lägga till fler attribut på <zone/>, men det är som du säger en avvägning mellan prestanda och informationsmängd. Till stor del beror det också på vad användarna av API:et kommer göra. Det skulle kunna vara en prestandavinst att lägga in all information i första steget redan när användaren hämtas, för att slippa fler requests till servern om zon-infon ändå alltid ska hämtas. Men å tredje sidan beror det också på var saker kan cacheas.

Jag noterar att ID fortfarande saknas bland <zone>-attributen, vilket gör det svårare att gå från
http://api.turfgame.com/v3/zones till http://api.turfgame.com/v3/zones/id:3002 Det går att gå via namnet, men det ser jag som en onödig felkälla med tanke på teckenkodningar och att namnen ändrar på sig.
Se http://issues.turfgame.com/view/115

Jag kommer också snart att rapportera en bugg angående "Content-Type"-headern som nu är text/html, den borde nog vara "text/xml" eller något annat som talar om att det handlar om XML.

Dom saknade zonid-attributen är det som jag ser som det största orsaken till problem när det gäller att använda nuvarande APIet. Det skulle vara otroligt skönt att ha zon-id för att kunna mappa direkt, utan omvägar och tvetydigheter. Är det förresten ens möjligt att fråga efter zonen "9/11Memorial" via namnet?

[UrbanGeeks]

http://wiki.turfgame.com/sv/wiki/TurfAPI_V3

v3 släppt
en del uppdateringar.
blocktid, revisits, date_taken, etc.

Trevligt att takeovers numer visar samma värde som turfgame.com (inkluderar revisits) och kul att APIet utvecklas!