DevProTalk

DevProTalk (http://www.devprotalk.com/index.php)
-   Planiranje i usability (http://www.devprotalk.com/forumdisplay.php?f=35)
-   -   API za web aplikaciju (http://www.devprotalk.com/showthread.php?t=1149)

Ilija Studen 18. 06. 2006. 09:49
API za web aplikaciju
 
Da li je neko do sada pravio API za web aplikaciju? Iskustva?

Cilj: jasan API za aplikaciju koja ima brdo asinhronih zahteva. Kad se već pravi nek bude napravljeno tako da može da se koristi i spolja, po potrebama.

Bojan Zivanovic 18. 06. 2006. 17:27
Nisam pravio, al kad bi pravio, REST all the way :1074:

Pedja 19. 06. 2006. 12:11
Ilija, da li mislis na API u nekom skript jeziku ili bas API u smislu neko kompletno okruzenje?

ivanhoe 19. 06. 2006. 15:42
Citat:
Originalno napisao Pedja
Ilija, da li mislis na API u nekom skript jeziku ili bas API u smislu neko kompletno okruzenje?

mozda sam ja glup, ali ja sam ziveo u ubedjenju da je API naprosto unapred definisani interfejs koji aplikacija implementira (odnosno spisak funkcija koje mozes pozvati)... o kakvom kompletnom okruzenju pricate i kakve ima veze u kom jeziku je API implementiran ? Poenta API-ja je da nije bitno u kom je jezikupravljen, nego samo da znas kako da ga pozoves..

Ilija Studen 19. 06. 2006. 17:28
Upravo tako, API je jasno definisan interfejs kojim spoljni programi mogu da komuniciraju sa samom aplikacijom. Jednostavno. Pravio sam gomile skripti koje imaju javan API - osoba koji radi Flash deo kaže koji podaci mu trebaju, ja kažem kako da formira upit i dobije te podatke kao XML iz PHP skripte. Samo što to nikad nisam zvao APIjem :)

Mada, ima tu i kvaka: autentifikacija, najbolje prakse itd. To je ono što me je zanimalo. Čisto ćeretanje na temu, dosta se nauči iz toga :D

--

Ono što je mene najviše zanimla je upravo autentifikacija. Generiše se API key koji je vezan za klijentovi IP adresu. Za JS same aplikacije on se generiše i dodeljuje automatski, za spoljne aplikacije genriše se na zahtev. Na osnovu ključa se određuje ko je korisnik i šta sme da radi. Sama razmena je klasika: na XML zahtev dobija se XML odgovor s tom razlikom što JS aplikacije može da traži i neke dodatne informacije kao što je recimo sažvakan template koji samo umetne u stranicu itd.

Neko radio nešto slično?

Dragi Tata 19. 06. 2006. 17:48
A što ne pogledaš SOAP? To je baš pravljeno za tu svrhu i radi manje-više kako treba. Doduše, koristio sam ga samo iz C++a i C#a ali sam siguran da postoji neka biblioteka i za PHP.

nixa 19. 06. 2006. 17:50
postoji preko PEAR ako se ne varam ....

Ilija Studen 19. 06. 2006. 18:57
Po tekstovima na koje sam nailazio čujem da je SOAP kabast, nepraktičan, preglomazan i sve što ga drži su velike firme i njihova PR mašinerija. Nikad ga nisam koristio niti sam se nešto udubljivao, ali previše pametnih ljudi (nemam linkove, na te tvrdnje sam nailazio povremeno) kaže da je smeće što je meni dovoljan razlog da ga obiđem.

Uglavnom, videh jedno krajnje jednostavno rešenje: XML zahtev - XML odgovor (možeš zatražiti i neki drugi format, YAML, JSON, bilo šta...). Za autentifikaciju se koristi najprostija HTTP autentifikacija (ili se može zakomplikovati ukoliko je potrebno). Jednostavno, radi posao i široko je podržano.

Dragi Tata 19. 06. 2006. 19:19
Citat:
Originalno napisao Ilija Studen
Po tekstovima na koje sam nailazio čujem da je SOAP kabast, nepraktičan, preglomazan i sve što ga drži su velike firme i njihova PR mašinerija. Nikad ga nisam koristio niti sam se nešto udubljivao, ali previše pametnih ljudi (nemam linkove, na te tvrdnje sam nailazio povremeno) kaže da je smeće što je meni dovoljan razlog da ga obiđem.
SOAP ima svojih mana, ali radi posao sasvim dobro i daje tačno ono što si tražio. Ako ti deluje preglomazno, pogledaj recimo XML-RPC koji je lakši i jednostavniji ali naravno i manje moćan.

marinowski 19. 06. 2006. 20:38
Ja preporucujem da se pogleda na koji nacin to rade 'veliki', pa da se na osnovu toga formira API. Izuzetno popularan je Flickrov api ( http://www.flickr.com/services/api/ ), ja sam ga koristio dosta puta, radi bez greske (ali sa namerno ogranicenom brzinom).

Za authentikaciju: sve zavisi do kojeg nivoa hoces da ides, uobicajeno je da se generise secret key koji se vezuje za unapred definisan user ID.

ivanhoe 19. 06. 2006. 21:27
paypal i ebay koriste soap za njihove API-je i meni je to bilo super za rad, vrlo je jednostavno za upotrebu i ima dosta gotovog koda za rad sa soap-om..
naravno kao i svaki xml i soap pati od toga da treba poslati puno texta svaki put za prenos relativno male kolicine podataka. Sto prenosis krace poruke to je izrazeniji ovaj problem..

Authentifikacija se kod gore pomenutih API-ja radi tako sto uz svaki soap upit saljes i username i password (odnosno secret key) i to je to..

Bojan Zivanovic 26. 06. 2006. 00:50
Za SOAP se obicno koristi nuSOAP biblioteka kod PHP-a...
Sad sam se bas igrao sa API-ima velikih igraca (Google, Yahoo,MSN posto sam pravio neki SEO script) i moram reci da mi je REST najprostiji..
GET, POST (il mozda PUT, DELETE) HTTP request koji vraca XML i kraj...
www.devprotalk.com/api/vesti vrati XML sa spiskom vesti npr..
Najprostije resenje, koje cu svakako primenjivati kad se za to nadje potreba..
Gledam, Flickr, Yahoo i gomila drugih vecih igraca nudi i REST API, a autorizacija ide preko tajnog kljuca koji se veze za username..

zira 26. 06. 2006. 05:56
nuSOAP
 
Radio sam SOAP API za http://www.tiketservis.com/affiliate i to radi fino (kada se ulogujes kao partner, mozes preuzeti kod sa primjerima i WSDL fajl)...

Koristen je nuSOAP koji mozes preuzeti sa http://sourceforge.net/projects/nusoap/ i nisu potrebni nikakve dodatne biblioteke.

Ako vise volis PEAR, imas
http://pear.php.net/package/SOAP

U principu nije nista komplikovano, samo treba fino planirati sta sve da ponudis u API-ju.

Ilija Studen 26. 06. 2006. 11:30
Citat:
Originalno napisao Bojan Zivanovic
Sad sam se bas igrao sa API-ima velikih igraca (Google, Yahoo,MSN posto sam pravio neki SEO script) i moram reci da mi je REST najprostiji..
GET, POST (il mozda PUT, DELETE) HTTP request koji vraca XML i kraj...
www.devprotalk.com/api/vesti vrati XML sa spiskom vesti npr..
Najprostije resenje, koje cu svakako primenjivati kad se za to nadje potreba..
Gledam, Flickr, Yahoo i gomila drugih vecih igraca nudi i REST API, a autorizacija ide preko tajnog kljuca koji se veze za username..
Koristiću upravo takav pristup. Jedno veliko ograničenje koje imam je da se sa APIjemo može komunicirati iz JavaScripta bez posrednika jer će client side deo aplikacije koristiti API za asinhrone zahteve. Pitanje je stvarno koliko bi se SOAP uklopio u takvu priču. Mozilla ima SOAP klijent, IE takođe kao neku ekstenziju, ali je to sve hakeraj u poređenju sa slanjem prostih HTTP zahteva i primanju odgovora.

Citat:
Originalno napisao zira
U principu nije nista komplikovano, samo treba fino planirati sta sve da ponudis u API-ju.
Naravno ;)

ivanhoe 26. 06. 2006. 17:05
pa SOAP je obican xml, nema tu neke toliko velike misterije, a xml koji se salje je uvek manje vise isti samo se par podataka menja, tako da nije veliki problem napraviti shablon XML-a koji se salje i onda samo zamenjivati promenjive pomocu javascripta pre slanja upita...

ja sam tako radio iz php za PayPal jer me mrzelo da koristim gotove velike klase za nesto toliko jednostavno..ovo je php varijanta, ali moze slicno i u javasriptu, bilo da ubacis promenjive direktno u string, bilo da koristis regExp da naknadno zamenis vrednosti:
PHP kôd:
/*** SOAP XML *************************************/
$SOAP_request = <<<End_Quote
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsd="http://www.w3.org/1999/XMLSchema"
    SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
    <SOAP-ENV:Header>
        <RequesterCredentials xmlns="urn:ebay:api:PayPalAPI" SOAP-ENV:mustUnderstand="1">
            <Credentials xmlns="urn:ebay:apis:eBLBaseComponents">
                <Username>$PP_USER</Username>
                <Password>$PP_PASS</Password>
                <Subject/>
            </Credentials>
        </RequesterCredentials>
    </SOAP-ENV:Header>
    <SOAP-ENV:Body>
        <GetTransactionDetailsReq xmlns="urn:ebay:api:PayPalAPI">
              <GetTransactionDetailsRequest xsi:type="ns:GetTransactionDetailsRequestType">
                     <Version xmlns="urn:ebay:apis:eBLBaseComponents" xsi:type="xsd:string">1.0</Version>
                     <TransactionID xsi:type="ebl:TransactionId">$TRANS_ID</TransactionID>
               </GetTransactionDetailsRequest>
                 </GetTransactionDetailsReq>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>
End_Quote;
/*** END SOAP XML *********************************/
mozes primetiti da se u ovom celom upitu samo 3 (i to vrlo kratka) podatka menjaju, sve ostalo je uvek isto...

Ilija Studen 26. 06. 2006. 19:26
OK, evo ga jednostavan primer. Hoćeš da imaš paginaciju gde se klikom na stranicu asihrono traže unosi za selektovanu stranicu i prikazuju. Kako bi to odradio pomoću web servisa koji koristi SOAP? Ili pak situacija gde se submituje forma i na osnovu odgovara (success ili error) prikazuje se ili poruka o grešci ili novokreirani objekat u listi.

Nikad nisam koristio SOAP tako da bi me zanimalo na šta ovakavi primeri liče i kako se realzuju.

Btw, što volim taj "enterprise" XML. Totalno je offtopic, ali sam uvek izbegao slična rešenje. Čim moraš da napišeš nešto takvo to je znak da treba da se počešeš po glavi i razmisliš da li si siguran da ti to treba... Šta fali nečem ovakvom:

Kôd:
<request key="..." reply_with="application/json">
  <param name="page" cast="int">12</param>
</request>
I to pošalješ na http://www.mojsajt.com/api/list_entries/. A odgovor je:

Kôd:
<response error="0" format="application/json">
<!-- Ovde ide JSON odgovor -->
</response>
Ili tako neka varijanta. Ovo je sve iz glave...

jablan 26. 06. 2006. 21:17
Citat:
Originalno napisao Ilija Studen
Čim moraš da napišeš nešto takvo to je znak da treba da se počešeš po glavi i razmisliš da li si siguran da ti to treba... Šta fali nečem ovakvom:
Hmm... Cross-platform compatibility? SOAP je defakto standard za veb servise.

Uzgred, jesi li siguran da paginaciju treba da trpaš u API?

marinowski 26. 06. 2006. 22:01
Zasto ne bi paginaciju stavio u API? Kako inace dobiti npr. objekte sa indeksom od 12.000 do 12.500 ?

Kao sto vec rekoh, pogledajte kako to rade veliki, ljudi se navikavaju da rade na taj nacin, a i ima razloga zasto su popularni.

Ilija Studen 26. 06. 2006. 23:00
Kad omogućiš da ograničiš skup objekata koje program vraća lako je realizovati paginaciju. Prateći efekat koji se lepo da iskoristiti. Zamisli da nemaš mogućnost ograničavanja, treba ti prvih 10, a u bazi imaš 15000 slogova (traćenje resursa).

@zigor: Pogledao sam Flickr API i Basecamp API. Više mi se sviđa Flickr zbog autentifikacije i zato što ne izgleda previše generički (kao Basecamp API). Da li imaš još neki API koji bi vredelo pogledati?

marinowski 27. 06. 2006. 11:11
Hm, vredi videti SXIP identity protocol, api je trivijalan, ali ideja o identitetu nije. O tome je vec bilo reci u drugom topicu. Sve zavisi u kojem ti se pravcu siri projekat. Ako dodje do toga da treba povezivati vise servisa, da bi bilo dobro da ti servisi budu povezani u jednu veliku celinu, a da korisnik bude identifikovan na svima od njih, onda mislim da SXIP itekako ima smisla.

Takodje vredi videti Google maps API, to je druga prica, posto je to javascript, ali dobro je da se vidi kako to izgleda kada se implementira u browseru. Interesantno je videti kako su presli sa verzije jedan na verziju dva protokola, ja bih rekao bezbolno, barem je nama bilo :)

Zasto ponavljam da API treba da lici na API koje rade veliki? Zato sto se onda programer koji povezuje servise lakse navikne, jer su velike sanse da je vec radio sa slicnim API-jem. Govorim iz licnog iskustva, objasnjavao sam na vise od 10 mesta kako se koristi API koji smo pravili, interesantno je kada ti se javi neko iz Izraela kome je znanje engleskog recimo na nivou da ga pozoves za Novu Godinu da ti prica, a tebi to sve smesno :) Na kraju je veza proradila, sto je najvaznije.

Ilija Studen 07. 07. 2006. 00:54
Postavio sam jedno polu teorijsko, polu praktično pitanje na SitePoint, ali ništa od odgovora. Uglavnom:

Citat:
I'm about to start working on API implementation for project management tool that I'm developing (see sig) and I have one question about API authentication.

I really like how Yahoo! does RESTful web services. Send request, get HTTP error or XML (JSON, YAML...) reply. But there is one thing that I don't really understand. Its token based authentication.

Process is pretty simple. In order to receive API key needed for authentication you need to go to website, login, set access permissions (read, read/write, levels) and when you hit submit you get redirected back to website that needs API key with generated API key. Than, and here is the part I don't understand, you need to request token. Later you use API key and token to use the service.

More details: http://upcoming.org/services/api/token_auth.php

What is the point of token? Both API key and token expire with time. Its much harder to guess two hashes than one, but still, if you have one you can retrieve other.

Any ideas. I have some, but still...
Izvinjavam se na lošem engleskom.

ivanhoe 07. 07. 2006. 05:44
ako sam dobro shvatio ti uzmes frob sa njihovog servera, i tim frobom mozes da generises veci broj zahteva tokom narednog minuta... ako bi sa zahtevima slao direktno frob onda bi neko mogao to da snifuje i da iskoristi u narednih minut taj frob da izda npr. zahtev koji kaze obrisi nesto i to bi proslo bez pardona...

ovako ti na osnovu frob-a generises token za svaki zahtev, i svaki put imas drugaciji token, ali oni tamo na serveru mogu da provere da su oni generisani pomocu njihovog frob-a, znaci mogu da te autentifikuju. Takodje (mada to nije nigde jasno objasnjeno) mora da postoji zastita da token moze da se koristi samo jednom, inace ne bi imalo smisla. Generisanje novog tokena za svaki zahtev (ali svaki put na osnovu istog froba) je uslov da to sve ima smisla...

Ilija Studen 07. 07. 2006. 08:54
Citat:
Originalno napisao ivanhoe
Generisanje novog tokena za svaki zahtev (ali svaki put na osnovu istog froba) je uslov da to sve ima smisla...
Token se ne genriše za svaki zahtev, već za jedan API key. Iz dokumentacije:

Citat:
Once the frob has been used to get a token, subsequent calls to getToken with that frob will produce the token (if unexpired) regardless of whether the frob is expired.
A evo šta je rekao Cal Henderson (jedan od ljudi iza Flickr APIja):

Citat:
the api key identifies an application, while a token identifies a
specific user using a specific application.
Ovde mi više liči kao da se API key generiše za pristup određene aplikacije sa sve podešavanjima za dozvole, a token mu više dođe kao session ID.

--

Po meni cela priča baš i nema previše smisla kad oba ističu. Razumeo bih situaciju kada API key ne bi isticao. Dođeš, generišeš API key, remote aplikacija to sačuva i kasnije se pomoću njega "loguje" na sistem, dobija token (session ID) i na osnovu ranije podešenih dozola za API key ima određene opcije na raspolaganju.

Suma sumarum: implementiraću kako smatram da je najbolje (pasus iznad) pa ako se nađe neko sa kvalitetnim predlogom za unapređenje samog sistema (a nadam se da hoće), uvek možemo da ga popeglamo. API mi treba jer će svi asinhroni zahtevi iz skripte ići kroz njega i njegovo odsustvo je jedini razlog zašto activeCollab nema NI JEDAN asinhroni zahtev u sebi (za sada).


Vreme je GMT +2. Trenutno vreme je 09:17.

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.