API za web aplikaciju

[ivanhoe]

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]

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]

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]

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.

Originalno napisao zira

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

Naravno

[ivanhoe]

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]

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:

<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:

<response error="0" format="application/json">
<!-- Ovde ide JSON odgovor -->
</response>

Ili tako neka varijanta. Ovo je sve iz glave...

[jablan]

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]

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]

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]

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.