ugrás a tartalomhoz

How to Manage the Risk of Losing API Access

MadBence · 2016. Jan. 26. (K), 15.31
Hogyan kezeljük a külső API-k használatából adódó kockázatokat
 ■
1

Örülök, hogy a "The Long-Term

inf · 2016. Jan. 26. (K), 23.11
Örülök, hogy a "The Long-Term Failure of Web APIs" után valami ilyesmi is bekerült a blogmarkok közé.
2

Szerintem nem véletlen :)

Joó Ádám · 2016. Jan. 26. (K), 23.42
Szerintem nem véletlen :)
3

Miért?

Hidvégi Gábor · 2016. Jan. 27. (Sze), 15.52
Ez az írás nem cáfolja meg az eredeti blogmark két kijelentését:
while web APIs enable us to tap into a wealth of data, they can only be relied upon in the short term
és
The end result is that developers are spending more time upgrading their software to ensure that it continues to work with web APIs they've integrated with, and less time adding the features and refinements that would really benefit their customers.

Ami számomra tanulság, hogy:
- csak akkor szabad igénybe venni egy API-t, ha van legalább egy alternatíva
- az n alternatíva metszetében lévő API parancsokat érdemes csak használni
- ki kell számolni, mennyi időben és pénzben a költsége az áttérésnek

Amit hiányolok, az a saját szerveren való gyorstárazás lehetősége, ha ez megoldható.
4

Miért csak read-only?

Max Logan · 2016. Jan. 27. (Sze), 18.50
Nem értem, hogy miért csak a read-only megoldásokat veszed alapul? Egy „értelmes” API egy cloud megoldás esetén read-write, és ha már, akkor a write szolgáltatja az igazi értéket.
5

Nem értem

Hidvégi Gábor · 2016. Jan. 27. (Sze), 18.57
Ez most hogy jön ide?
6

Idézet

Max Logan · 2016. Jan. 27. (Sze), 19.00
Amit hiányolok, az a saját szerveren való gyorstárazás lehetősége, ha ez megoldható.
7

Itt olyanokra gondoltam, hogy

Hidvégi Gábor · 2016. Jan. 27. (Sze), 19.14
Itt olyanokra gondoltam, hogy letöltöm saját szerverre pl. a facebook bejegyzéseket, a twitter üzeneteket, RSS-eket, tumbler képeket, és onnan szolgálom ki, mert az a biztos, ami nálam van.
8

Yes, de ennek semi köze az

Max Logan · 2016. Jan. 30. (Szo), 12.42
Yes, de ennek semi köze az API-k használatához. Ez egyszerűen vizuális tartalom a szöveges környezetben. A print médiában ezt a fényképezés, az online médiában az online dolgok vonatkozásában pedig a screenshot készítés hivatott megoldani.

Ahogyan mondtam, az ilyen beágyazós dolgok megítélésem szerint nem minősülnek API használatnak, mert effektív kapcsolatod nincsen az SDK-val, egyszerűen beágyazol egy kódot, amire a legbénább felhasználó is képes.

Csak, hogy érthető legyen:
  • Application programming interface
  • Software development kit
9

Tévedsz, a Facebook

Hidvégi Gábor · 2016. Jan. 30. (Szo), 13.18
Tévedsz, a Facebook bejegyzéseit a Facebook saját API-jával lehet lekérdezni (s ugyanígy a Twitternél és társaiknál), és az teljesen irreleváns a felvetett témával kapcsolatban (How to Manage the Risk of Losing API Access), hogy használod-e írásra a parancsokat vagy sem.

Miért akarna mindenki írni? Az online újságok tipikusan read-only médiumok, akik statikus tartalommal dolgoznak. Számukra az adatok lekérése pontosan ugyanolyan fontos, mind számodra, aki egy API-t – a leírásaid alapján – úgy vesz igénybe, hogy kihasznál minden benne rejlő potenciált.
10

Amiről én beszélek az egy

Max Logan · 2016. Jan. 30. (Szo), 17.07
Amiről én beszélek az egy Facebook szolgáltatás átlagfelhasználóknak (bejegyzés beágyazása honlapba) vs. programozóknak (!) készített háttérrendszer hasznlata. Az a jelen kontextusban tök lényegtelen, hogy értelemszerűen előbbi lehetőség is valamilyen publikus API-t használ. (Messze vezet, és csak megemlítem: egy URL struktúra, ami statikus tartalomra mutat, már önmagában tekinthető read-only API-nak…)

Az újságírónak fogalma sincsen arról, hogy a HTML kód mit és miként csinál, ő egy copy-paste harcos. Ha nem aludt az elmúlt 15 évben, akkor a saját munkájának minőségét emelendő (vagy inkább megtartandó), screenshot-ot csinál egy Facebook bejegyzésből, nem pedig beilleszti azt.

Már csak azért is, mert számos példa volt arra, hogy megváltozott, vagy pár óra alatt törlésre került egy-egy ilyen megosztás, így a cikk, hír, blogbejegyzés, akármi az eredeti formájában értelmét vesztette.

Itt tehát van egy kényelmi szolgáltatás, amit nem használ épeszű online médium, ha a célja az, hogy a publikációk tartalmi egysége az idők során változatlan maradjon.

Nem véletlen, hogy mondjuk az ilyen-olyan 20-30-50 elemű listák, amik a honlapok design-jának méltatására készültek, screenshot-ot mutatnak az oldalról. Volt, hogy 1 évvel később találtam meg a cikket, és a linken már egy teljesen más kinézetű tartalom jelent meg.

Ilyen szinten ezek a szolgáltatások a pillanatnyi tartalomfogyasztás eszközei, nem pedig az online archívum jellegű tartalomgyártást hivatottak szolgálni. Aki tehát utóbbiban érdekelt, nem, vagy csak átmeneti jelleggel használja a beágyazás lehetőségét. Ami programozói értelemben nem API használat, mert az API-t programozás útján használjuk fel.

Az eredeti cikk pedig emlékeim szerint messze nem az ilyen beágyazós dolgokról szólt, hanem a programozók által felhasznált API-król, majd azokkal üzleti alapon megépített szolgáltatásokról.