Vlákno názorů k článku
Firefox a Chrome se obávají problémů s trojcifernou verzí v řetězci User-Agent od anonym - Upřimě, každý kdo vytvoří kód, který si při...

Upřimě, každý kdo vytvoří kód, který si při čtení verze neporadí s přechodem od dvouciferné verze na třícifernou, zaslouží kopanec do intimních míst. Stejně jako ten, kterého napadlo převádět datum/čas z řetězce přímo a bez řádných kontrol či pojistek na integer*. Ikdyž toho by měli rovnou vyhodit. Z "wokna" :-D

* AV scanner MS exchange. Převáděl řetězec data/času ve formátu YYMMDDSSSS na 32 bitový signed integer a v roce 2022 nevyhnutelně přetekl.

Vždycky jsem si říkal, že to snad někde vyučují a ono, ano, vlastně vyučují. Nevím přesně jestli to má jméno, ale je to ten "minimalistický" přístup k vývoji alá "udělám přesně a jenom to co je předemnou, až bude potřeba víc, tak 'se' to udělá/přidá", Komunita vývojářů okolo Javascript/React (co vím) je toho plná.

A tak se vám například stane, že přijdete k API která nemá pro základní/hlavní entitu, okolo které je to celé postavené, vyhledávání podle více id najednou, protože se čekalo, až jednou bude něco takového nějaký klient potřebovat - takže API to neumí - vývojáři nemají čas - jiné deadlines a klient to tedy nemůže implementovat. Koho by napadlo, že by v mnoha-produktové centrální API mohl někdo vyhledávat podle více id? (to se opravdu stalo a není to tak dávno). No, hlavně že v nějaké knížce o API nějaký inteligent vymyslel, že stylové je si hezky ORM požádat o každou entitu zvášť. WTF OMFG ... A teď nás připojili na druhý takový genitální výtvor. Takže, nespadněte smíchy ze židle, entity se dají hledat jenom jednotlivě podle id a ne podle (nazvěme to kategorií) kategorie. Je to jako byste v eshopu hledali výrobek podle přesného id, podle data přidání nebo stránky. Genitální.

Dál už psát nebudu, protože to bez sprostých slov nejde. Tak jsem musel stahnout API stránkovanou do jednoho souboru a hledat si v tom sám grep/regexp. Good job. Ti lidi fakt nepřemýšlí ....

17. 2. 2022, 13:32 editováno autorem komentáře

"Nikdy není dost času na to, aby se to udělalo dobře. Ale vždy je dost času na to, aby se to udělalo znovu."

Aneb, zakaznik dostane to, co si zaplatil.

A pak se objevi zranitelnost ve funkci, ktera nebyla v zadani a programator bude zazivat horke chvilky.

> Jaroslav Beneš

Pak je chyba, že takový endpoint není v zadání. A když tam není, tak má programátor řvát - stejně se to s ním konzultuje.

To motáte dohromady dvě dost rozdílné věci. Jedna věc je zprasit parsování verze tak, že si neporadí se situací, kdy je číslo trojciferné. (Což mi přijde, že je složitější a pracnější udělat špatně, než to udělat dobře.)

A druhá věc je, jestli máme do API / aplikace implementovat funkcionalitu, která "by se možná mohla někdy hodit". Tady to je ve skutečnosti docela komplikovaná otázka. Strávit 50% vývoje na funkcích, které nikdo nikdy nepoužije, evidentně není moc efektivní přístup. Na druhou stranu, dělat jen přesně to, co je aktuálně požadováno a ani o ždibíček víc je zase druhý extrém, který člověka může lehce dostat do slepé uličky. Takže to chce zkušenosti a cit rozhodnout, kde ten design trochu rozšířit a kde to nechat na budoucnost. Třeba i v té formě, že to sice nenaimplementuji, ale design udělám tak, že to v budoucnu bude jednoduché rozšířit.

> L

No, tak možnost dotázat se na entity podle (multiple) id mi nepřipadne jako něco co "by se mohlo hodit", ale co je snad nejmasovější užití - kolik jste viděl systémů, které neustále a naprosto pracují vždy jen a pouze s jednou entitou? Já snad ještě ani jeden (ale jistě se nějaký krajní případ najde). A přitom implementace takového endpointu je v podstatě stejně triviální jako implementace endpointu pro dotaz nad jedním jediným "id". Takže ne, tu vaši pointu neberu. Takový chybějící endpoint buď lennost, nebo naprostá neznalost. Nebo oboje.

Takže to chce zkušenosti a cit rozhodnout, kde ten design trochu rozšířit a kde to nechat na budoucnost.

Což je tak zhruba to, co jsem napsal. (viz odstavec výše)

17. 2. 2022, 21:00 editováno autorem komentáře

Ono totiž třeba v REST API není moc jak hodně ID entit poslat. V url path těžko. Query param vypadá na první pohled pěkně než narazíte na omezenou velikost URL. Header možná, ale někde se headry nepoužívají a musí se nastavit gateway aby je propouštěla. Pak zbývá v body. No ale pak zase nejde použít GET a POST na vyhledávání zrovna není nejčistší.

Já jsem dotaz na multiple entities podle id (!) potřeboval naposledy... no, to už bude dávno.

Navíc sám píšete "protože se čekalo, až jednou bude něco takového nějaký klient potřebovat", tedy evidentně se to API už nějakou dobu používalo a nikomu tahle funkcionalita nechyběla. Takže ne, tu vaši pointu neberu.

U nějakých legacy systémů, které běží na HTTP/1.1, se to může hodit. U nových systémů, které používají HTTP/2, je to klasická předčasná optimalizace, která nakonec věci akorát komplikuje a zpomaluje. Stačí jeden endpoint pro jedno id, když jich potřebuju víc, zavolám ten endpoint opakovaně. Nemusím vytvářet nový endpoint, bude dál fungovat kešování, data pro jednotlivá id bude dostávat postupně tak, jak jsou k dispozici – takže klidně můžu uživateli zobrazit 49 položek, se kterými on už může pracovat, a nemusí se čekat, až se táhne 50. položka, která třeba z nějakého důvodu trvá déle. Dál funguje i horizontální škálování, nemusí mi všechny položky vracet jeden server.

Takže takový chybějící endpoint není lenost nebo neznalost, naopak to může být znalost a používání moderních technologií.

To je tak, kdyz na vsechno je framework, ze kterych to prece slepime. A ten framework dela kde kdo, kdo ma do zadku diru. Coz by jeste bylo ok, kdyby nemel tu drzost cpat to ostatnim, jako to nej cool reseni.

Spis je na zamysleni ze programator musi myslet na nejake kontroly u takto primitivni ulohy. Tohle by mel mit kazdy system uz v sobe ze provede parsing do pozadovaneho formatu.Ted mame ze kazdy si to dela po svem a pak resime jestli ten nebo ten program nespadne.
Ale uz je pozde, uz to tak je, tak hold musi programator myslet i na takovou vec.