User interfacenek tekinthető-e egy API?

A curl is egy CLI parancs.

És az API, amikor a Firefox címsorába írom be, hogy ceg.hu/alkalmazottak?

A fejlesztő nem használja, a fejlesztő által elkészített program használja.

A curl parancsnak a kapcsolóit nevezheted UI-nak, amit kiír pedig a curl kimenete (amit történetesen egy API-tól kapott, na bumm).

--
openSUSE - KDE user

Az API egy függvény- és eljárás halmaz, amit az alkalmazások használnak. A CLI parancs az nem API, az egy eszköz (alkalmazás) ami használja az API-t. A CLI UI-nak tekinthető, az API nem. Szerintem.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

Nyilván úgy, hogy usernek csak azt tekinthető, aki személyi azonosítóval rendelkezik, egy alkalmazás nem.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

Ok, akkor legyen úgy, hogy az "end user" legyen csak egyszerűen user, minden más user az programozó, fejlesztő, egyéb állatfaj. Az nem autó, amiben nincs kormány, csak a helye, és egy fogóval kell tekergetnem a tengelyt. A programozó se állandóan az API-t használja, hanem ráköti a programot, és megy tovább a dolgára. Nyelvileg "use" ez is, de a user az IT-ban nem annyit jelent csak, hogy felhasználó, hanem az, aki nem fejleszt, hanem leül, és amit szabad megnyomja. Meg azt is, amit nem, de az nem a feladata :).

"Ami kód által feldolgozásra, az API. "
Azt viszont ne feledd, hogy minden API, minden domain modelling valamely szempontból, valamilyen szemszögből modellezi az adott domaint.
És a hívó kód szemszöge más lehet, mint amit az API kitalálóinak a szemszöge.

Lehet, hogy ez korlát, de a gyakorlat azt mutatja, hogy sok szoftvernek hosszú távon karbantarthatónak kell lennie, vagy legalább képesnek arra, hogy alapvető módosítás nélkül hozzá merj nyúlni.

A másik ilyen dolog az, hogy a kódoptimalizálást, amire szabályok vannak, miért agyban akarjuk elvégezni, amikor elvégezheti gép is, ugyanazokat a szabályokat alkalmazva?
Hiszen ezért írunk magasszintű nyelveken, ahol már van olyan alapvető absztrakció, mint lebegőpontos szám, egész szám, karakter adattípus. Igen, maga az adattípus is egy absztrakció, hiszen a gép csak memóriacímet meg bitmintát lát, bármikor összead neked két memóriaelemet, akkor is, ha az egyik egy karaktert, a másik meg egy lebegőpontos számot tartalmaz.
Azért vezettünk be egyre magasabb szintű absztrakciókat, hogy egyre több minden dolgot írhassunk le úgy szoftverrel, hogy nem kell hozzá iszonyatos embertömeg és dokumentáció.
Egyszerűen szólva: a gépi kód írása nem skálázható.
Például nem dokumentálod le memóriacímek szerint a tárolt adatok típusát, mert nem kell - elvégzi helyetted a compiler.

A harmadik ilyen dolog a villamos-kompatibilitás: ha abban bízunk, hogy vna a cégben pár zseni, aki átlátja a kódbázist, és nélkülözhetetlenek a rendszer működtetéséhez, mert optimális kódot írnak, amit amúgy junior programozók képtelenek, akkor ha ez a pár zseni nyugdíjba megy, elüti a villamos, megveszi egy másik cég, vagy bármilyen más okból nem elérhető, akkor bukott a mutatvány.

Egyszerűen a gépileg optimális kód írása nem skálázható olyan mértékben, amit szeretnénk. Nem csak költségről van itt szó, hanem lehetőségekről is.

Az hogy user friendly nem fekete-fehér kérdés, egy SQL lekérdezés megírásához kell ismerni azt a nyelvet, ez van, nem nem-user-friendly, hanem van egy előkövetelmény. Látom hol lehet belekötni mindkét végletbe, de szerintem a user friendly-ség sem értelmezhető előkövetelmények nélkül, pár éve a fél világ rühellte az érintős dolgokat, majd pár év alatt tök természetes lett. De egy rakás félretárcsázás, hopp-töröltem-bocsi, ésatöbbi volt előtte.

Amúgy nem igazán tudom értelmezni, hogy egy API-ról mi alapján lehetne eldönteni, hogy user-friendly-e az API vagy nem.
Minden egyes API elemnek (osztálynak, interfésznek, metódusnak, paraméternek) értelme és célja van.

Mégpedig az, hogy valamely szempont szerint modellezzen egy domaint, a benne lévő elemeket és műveleteket. Azaz ebben sehol nincs benne, hogy az API user friendly legyen, hiszen az elterelné a lényegről a figyelmet. Ha például a user friendlység miatt kihagyunk valamit az API-ból, akkor előfordulhat, hogy a keletkező API-val már nem tudunk leírni valami olyan folyamatot, amit le kellene. Így maga a user friendlység sok esetben nem cél.
Hogy egy hasonlattal éljek: a GNOME 3 UI lehet, hogy user friendly, de sok mindennek a lehetőségét meg is vonja a felhasználótól.

Ettől még lehet cél az, hogy a gyakori felhasználási eseteket könnyen lehessen kifejezni az API-val (tipikusan: értelmes defaultok használata), míg a többi esetet is ki lehessen ugyan fejezni, de dolgozni kell hozzá. Hogy egy közismert elv alapján mondjam: a Pareto-elvet lehetne szem előtt tartani, aka 80-20-as szabályt (természetesen lehet ez 70-30 is, csak szemléltetés a lényeg): az API használati lehetőségeinek 80%-át leíró hívó kód mérete, meg a 20%-nyi lehetőségeket leíró hívó kód mérete álljon 20-80 arányban.
Erre már lehetne azt mondani, hogy ez az API user friendly valamilyen szempontból.
De amíg nem mondod meg, hogy mit értesz az alatt, hogy user friendly egy API, vagy nem, addig nem értelmes a kérdés szerintem.

Az UI ember–gép kapcsolat, míg az API gép-gép kapcsolat célját szolgálja.