Kā jau lācim komentāros paredzēju cilvēki ir sākuši rakstīt wrapperus Draugiem.lv nesen palaistajam API.
Cik man zināms, pašlaik ir publicēti divi varianti:
- .NET variants: http://dotnet.lv/blogs/ia/archive/2008/12/06/draudz-g-s-saskarnes-iesai-ojums.aspx
- PHP variants: http://defektologs.lv/2008/12/07/draugiemlv-api-php-wrapper
Nu šiem pievienojas arī trešais- mans Python variants. Uzreiz gan vēlos pateikt, ka Pythonā neesmu diez ko profesionāls, tāpēc varētu būt, ka šo pašu kodu ir iespējams uzrakstīt arī daudzkārt efektīvāk un īsāk, taču "tas kods ir tāds kāds viņš ir"TM.
Lai palaistu šo wrapperi, nepieciešamas urllib un lxml bibliotēkas. Pirmā ir pieejama katrā kaut cik modernā Python instalācijā, otro var dabūt šeit.
Wrappera kods ir pieejams šeit. Centos wrapperi veidot pēc iespējas vienkāršāku lietotājam, taču vai izdevās- īsti nezinu :>
Zip failā ir iekļauts drapi.py fails un ar pydoc.py automātiski uzģenerētā dokumentācija failā drapi.html.
Koda izmantošana:
Vispirms importējam visu no moduļa:
from drapi import *
Tad izveidojam drapi objektu, kā pirmo parametru padodot appkey, ko mēs iegūstam savu aplikāciju reģistrējot draugos:
api = drapi('<appkey šeit>')
Ja ir pieejama arī lietotāja atslēga (katram lietotājam šī atslēga ir individuāla, un man to labāk patīk saukt par userkey, nevis apikey), tad kā otro parametru var norādīt arī šo atslēgu.
Tā kā pieņemu, ka mūsu aplikācija vēl nav dabūjusi lietotāja atslēgu, sākam autorizācijas procesu ar e-pastu, kas iegūts no gala lietotāja:
authcode = api.start_authorization('my-email@domain.tld')
Ja Python konsole turpina darboties, kamēr lietotājs atļauj aplikācijai piekļuvi, tad nav vajadzības glabāt authcode, jo tas tiek glabāts arī api objektā.
Tālāk, kad lietotājs ir atļāvis aplikācijai piekļūt saviem datiem, pabeidzam autorizāciju un iegūstam userkey'u:
userkey=api.finish_authorization('<auth code vērtība>')
Šis userkey's arī glabājas api objektā, taču šo noteikti vajadzētu saglabāt, lai nenākas atkārtot šot lietotājus atbaidošo procesu.
Kad ir iegūts userkey's, varam sākt pilnvērtīgi izmantot api:
print api.get_messages()
print api.get_activities()
print api.get_counters()
print api.get_user_data()
Un nobeigumā, neliels paraugs, kā apstrādāt kļūdas:
from drapi import *
try:
api = drapi('xxxxxxx','xxxxxxx')
#print api.start_authorization('my-email@domain.tld')
#print api.finish_authorization('asdasdasd')
print api.get_messages()
print api.get_activities()
print api.get_counters()
print api.get_user_data()
except APIError, e:
print 'Kļūda #'+e.code+': '+e.description
Gaidīšu ieteikumus, kā šo API varētu uzlabot.
P.S. Gandrīz aizmirsu: testēts, rakstīts un sists tika uz Python 2.5.2. Nezinu kā ir ar versiju atšķirībām, taču nekam drastiski savādākam 2.6 versijā nevajadzētu būt.
P.P.S Aizmirsu piebilst, ka šis kods ir licenzēts ar manu īpašo "dari-ar-šito-kodu-ko-gribi-kaut-vai-izdrukā-un-slauki-pakaļu" licenzi :>
Komentāri
Kāpēc neizmantoji kādu no
Kāpēc neizmantoji kādu no pitona standarta bibliotēkā iekļautu xml parsēšanas bibliotēku?
Piemēram ElementTree: http://docs.python.org/library/xml.etree.elementtree.html
Izmantošanas piemēri: http://effbot.org/zone/element.htm
Kā arī operatora <> vietā ir labāk lietot !=, jo pirmais ir skaitās lieks - 3.0 versijā tas vispār ir izmests ārā.
bubu, godīgi sakot, šo
bubu, godīgi sakot, šo bibliotēku sāku lietot, kad iepriekš vajadzēja atrast elementu pēc XPath, tāpēc izmantoju to arī šoreiz, jo biju jau pieradis. Bet paldies par padomu, apskatīšu šo bibliotēku.
Kas attiecas uz otro ieteikumu: paldies, salaboju. Nezināju, ka šis operators jau skaitās deprecated ;)
Es tieši no ElementTree
Es tieši no ElementTree pārgāju uz lxml. Bet neatceros kāpēc. Liekas, ka ātrdarbības un vienkāršuma dēļ, bet neapgalvoju.
Bet tādēļ jautājums bubu - ar ko ElementTree ir labāks? Tikai tas, ka tas ir standarta komplektācijā?
Jā, ka standarta
Jā, ka standarta komplektācijā - mazāk čakara lietotājam instalēt dīvainas bibliotēkas ;) Vismaz manās acīs tas ir neliels mīnusiņš, ka tik vienkāršai bibliotēkai ir tāda atkarība.
Domāju, ka apspriest ātrdarbību xml parseriem ir lieka šim wraperim. Nav jau miljonu baitu jāparsē. Man jau tas ElementTree šķiet ārkārtīgi vienkāršs un ērts lietošanā. Ja nu tas neapmierina, tad var arī apskatīt paņem kādu citu bibliotēku, pitonam ir vairākas xml parser-bibliotēkas, tai skaitā SAX un DOM parseri: http://docs.python.org/library/markup.html
Nu jā, par ātrdarbību īpaši
Nu jā, par ātrdarbību īpaši neiespringu, kad rakstīju to kodu. Par atkarību- taisnība, ka liekas atkarības nebūtu vajadzīgas, ja var iztikt ar standarta rīkiem, taču es jau biju iestrādājies ar lxml bibliotēku, tāpēc negribējās pētīt citus variantus, jo šis pats izskatījās tīri ok.
Cik paskatījos, tas ElementTree arī ir diezgan vienkāršs, taču atklāti sakot, man nav īpašas gribēšanas tagad pārrakstīt to wrappera daļu, jo neba jau es ceru, ka kāds viņu izmantos- mācību nolūkos rakstīju. Kaut gan, ja kādu nakti nebūs ko darīt, tad moš arī pārrakstīšu, izmantojot standarta bibliotēkas.
Tu jau zini, ka iekš
Tu jau zini, ka iekš drapi.get_activities() Tev ir piemirsies pēdējā ciklā inkrementēt "i", ne? :)
Godīgi sakot, kodu tā arī
Godīgi sakot, kodu tā arī nekur izņemot vienkāršā testa aplikācijā neesmu pielietojis, tā kā nebiju gan pamanījis. Liekas, ka jau nākušas klāt jaunas fīčas, kuras wrapperī vēl nav ieviestas, un visdrīzāk, kamēr man neparādīsies vajadzība pēc wrappera, arī fīčas neparādīsies.
Paldies par norādi, izlaboju arī publicētajā versijā.
Pievienot jaunu komentāru