Vidite svet velmi naivne vid "Uz jenom na RPC mame Corbu, RMI, XML-RPC, SOAP, JAX-RPC, MSRPC, (D)COM, AMF, ... " niektore technologie su zastupitelne inymi niektore nie. Ked budete chciet RPC na napr nejakom embedded rieseni tazko asi pouzite SOAP alebo nieco na sposob XML. Takze cakat, ze na vsetko bude jeden univerzalny framework je uplne mimo. Stale tu totiz vidite iba web sluzby ale mozno vas prekvapi existuju aj ine applikacie a ine poziadavky. Navyse podotkol by som, ze ocakavam ze casom bude APIARY pohltene niekym velkym, pretoze samo o sebe asi nebude mat silu (zdroje) byt top hrac. Co je ale asi bezny postup pri podobnych technologicky orientovanych firmach.
V mnoha (drtive vetsine) pripadu se k api ani k domunentaci nedostanete, pokud nemate koupenou prislusnou aplikaci ... chci videt, jak budou doticni utracet miliony a miliony $$$ ... za nakupy vsemoznych aplikaci, ktere nanic nepotrebuji.
Mnoho aplikaci je navic dodavano se vsemoznymi NDA.
Pokud navic zminujete trebas banky, tam zakaznici velmi casto pozaduji hodne velke (financni) zaruky. Opet, chci videt, jak se budou zarucovat, ze zaplati desitky milionu smluvnich pokud ... az se neco podela.
A i pokud se vyhneme extremum, zcela klasicka je situace, kdy jeden svadi nefunkcnost na druheho ... a v tomto pripade jeste na tretiho ...
Po deseti letech si nemohu odpustit napsat nazor do diskuze.
To co Jakub Nešetřil se svym tymem buduje je jeden z nejslibnejsich SW pocinu nejen v Cechach, ale myslim ze v celem IT. Podivejte se do historie jak vznikaji API (formaty/protokoly) nad ruznymi systemy a jak jsou navzajem (ne)kompatibilni, jak se doplnuji a v dusledku pouzivaji. Uz jenom na RPC mame Corbu, RMI, XML-RPC, SOAP, JAX-RPC, MSRPC, (D)COM, AMF, ... to jenom pro nazornost jak se neumime domluvit a standardizovat nejakou technologii (z casti asi i zamernou izolaci vendoru v ramci konkurencniho boje).
Pokud jako vyvojar mate dobry napad na nejakou aplikaci/sluzbu/... typicky chcete resit tento napad a ne podruznosti jako jak se pripojit k tomu nebo onomu subsystemu. Kazdy rozumny developer takovy kod (connector/adapter) separuje a izoluje od sveho systemu.
Spousta z techto API je casto malo nebo vubec zdokumentovana (typovy system pomahaale behavioralni popis je u slozitejsich veci nutny).
Pokud me nekdo zadarmo nebo maly poplatek nabidne dobre zdokumentovanou sadu techto konektoru/adapteru nebo dokonce fasad, unifikuje mi pristup ke sluzbam a aplikacim ve svete. Tim me prece setri cas a energii, ktere muzu venovat na tuneni sve aplikace/sluzby. Takova aplikace je pak mensi, jednodussi a tudiz pravdepodobne i mene zabugovana (mensi naklady na maintainance).
Treba napojeni existujicich aplikaci ceskych bankovnich domu na CUZK a jeho nove API se pohybuje v milionech CZK. Kazda banka to navic resi znovu po svem (z casti nutnosti rozdilnosti internich systemu, z casti proto, ze neexistuje stabilni adapter). Nebo kolik blogovacich systemu nebo socialnich siti (kazdy se svym API) existuje... pokud chci vedet o obecne udalosti v nejakem z nich, bud si napisu 42 adapteru a konektoru nebo vyuziju fasadu/adapter co napsali borci v ApiAry a mam je poresene za jednotnym API.
Panu Nešetřilovi gratuluji k dobrym napadum a preji silu a vytrvalost...
Peace ;-)
Pavel Rousar
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).
