DevProTalk
Strana 2 od 3 < 1 2 3 >
Prikažite 40 poruka iz ove teme na jednoj stani

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)

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.


Vreme je GMT +2. Trenutno vreme je 23:53.
Strana 2 od 3 < 1 2 3 >
Prikažite 40 poruka iz ove teme na jednoj stani

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.