https://plamosoku.com/enjyo/api.php?action=feedcontributions&feedformat=atom&user=Tina46J44515 2026-10-15T03:23:29Z 利用者の投稿記録 MediaWiki 1.36.1 https://plamosoku.com/enjyo/index.php?title=Co_zrobi%C4%87,_kdy%C5%BE_se_odpov%C4%9B%C4%8F_API_v_Postmanu_neshoduje%3F&diff=3240788 2026-10-11T20:28:53Z

<p>Tina46J44515: ページの作成:「Nakonec počítejte s tím, že každá horká oprava něco stojí: přerušenou práci, vyšší riziko regrese a únavu lidí, kteří ji vydávají. Proto se vyplatí…」</p> <hr /> <div>Nakonec počítejte s tím, že každá horká oprava něco stojí: přerušenou práci, vyšší riziko regrese a únavu lidí, kteří ji vydávají. Proto se vyplatí sledovat, kolik jich za měsíc skutečně máte. Když jich přibývá, není problém v rychlosti týmu, ale v kvalitě vstupu — v testech, kontrole změn nebo v tom, jak rychle se rozhoduje o prioritách. Snižovat počet oprav znamená zpřísnit podmínky pro jejich vznik, ne zrychlovat jejich vydávání.&lt;br&gt;&lt;br&gt;Poslední věc, kterou vývojáři podceňují, je řazení. Bez explicitního ORDER BY databáze negarantuje stabilní pořadí a paginace se rozsype. Vždy řeďte podle unikátního klíče, případně přidejte id jako tiebreaker. Jinak se vám při každém dalším dotazu mohou stránky míchat, i když se data nezměnila.&lt;br&gt;&lt;br&gt;Častou chybou je posílání neplatného JSON. Přebytečná čárka za poslední položkou nebo chybějící uvozovky způsobí, že server vrátí 400 a v těle uvede chybu parsování. Další chyba je špatně nastavená hlavička Content-Type, kdy server data nepřečte, i když jsou syntakticky správně. Pozor také na diakritiku v hodnotách, pokud ji neošetříš kódováním. U autentizace si ověř, že token neobsahuje mezery na začátku nebo na konci, protože je snadné je zkopírovat spolu s ním.&lt;br&gt;&lt;br&gt;Kdy kontrolovat stavový kód a kdy tělo odpovědi Stavový kód 200 nebo 201 znamená, že požadavek prošel, ale nevypovídá nic o obsahu. V záložce Tests napiš kontrolu, která ověří obojí. Příkladem je pm.test s ověřením pm.response.to.have.status(200) a druhý test, který zkontroluje, že v těle je očekávané pole. U chybových stavů 400 a 404 zkontroluj, zda odpověď obsahuje konkrétní chybovou zprávu, a ne obecné selhání. Testy se spouštějí při každém odeslání a výsledek vidíš hned pod odpovědí.&lt;br&gt;&lt;br&gt;U každého požadavku nastav metodu, hlavičky a tělo. Pro JSON posílaný v těle zvol raw a typ JSON, hlavičku Content-Type nastav na application/json. U autentizace nepřidávej token ručně do každého požadavku. Zvol záložku Authorization, typ Bearer Token a hodnotu načti z proměnné. Pokud token vyprší, v odpovědi dostaneš stavový kód 401 a nebudeš muset procházet všechny požadavky. Do hlaviček patří i Accept s očekávaným typem odpovědi.&lt;br&gt;&lt;br&gt;Když testy projdou jednotlivě, spusť celou kolekci pomocí Collection Runneru. Nastav počet opakování a zpoždění mezi požadavky, aby server nezahltil. Do proměnných můžeš ukládat hodnoty z odpovědí, například id nově vytvořeného záznamu, a použít je v dalším požadavku. Tím ověříš návaznost celého scénáře, ne jen izolovaných volání. Po dokončení runneru zkontroluj přehled výsledků a selhané testy si projdi jeden po druhém.&lt;br&gt;&lt;br&gt;Začněte tím, že si odpovíte, co je kód a co konfigurace. Kód je to, co se kompiluje nebo interpretuje a co by mělo být stejné ve všech prostředích. Konfigurace je to, co se mezi prostředími liší: připojení k databázi, klíče, limity, zapínání funkcí. Do kódu nepatří žádné hodnoty specifické pro prostředí. Do konfigurace nepatří logika. Tuto hranici si napište a vynuťte ji v CI, ne jen v hlavách.&lt;br&gt;&lt;br&gt;Základem je chápání pořadí middleware. Express prochází vrstvy v tom pořadí, v jakém jste je zaregistrovali. Chybový middleware se pozná podle čtyř parametrů: (err, req, res, next). Pokud jeden vynecháte, Express ho bude považovat za běžný middleware a chybu nezachytí. Chybové vrstvy patří až na konec, za všechny routy a za obsluhu 404.&lt;br&gt;&lt;br&gt;Konfiguraci dělte podle prostředí, ale ne pomocí větvení v gitu. Větve pro vývoj, test a produkci vedou k nekonečnému mergování a rozjetým rozdílům. Lepší je jedna větev a adresářová struktura: například base, vyvoj, test, produkce, kde se hodnoty překrývají. Tajemství nepatří ani do jednoho repozitáře. Držte je ve správci tajemství nebo v šifrovaném souboru, který se odemyká při nasazení. Do gitu patří jen odkaz na tajemství, ne jeho obsah.&lt;br&gt;&lt;br&gt;Dva repozitáře a jedna smlouva Nejčastější a nejčistší uspořádání jsou dva repozitáře: jeden pro kód, druhý pro konfiguraci. Kód se nasazuje jako artefakt, konfigurace se dodává zvlášť. Aby to fungovalo, potřebujete smlouvu: seznam klíčů, jejich typy a výchozí hodnoty. Ten patří do kódu, protože je součástí rozhraní aplikace. Konfigurační repozitář pak obsahuje pouze hodnoty pro jednotlivá prostředí. Když se přidá nový klíč, změní se nejprve smlouva v kódu, teprve potom hodnoty v konfiguraci. Nikdy naopak.&lt;br&gt;&lt;br&gt;Výsledkem je čitelná historie, bezpečnější tajemství a možnost vrátit kód i konfiguraci nezávisle. Není to o nástroji, ale o disciplíně: kód a konfigurace mají různé vlastníky, různé tempo změn a různé dopady. Dokud je držíte pohromadě, platíte za to při každém incidentu.</div>

Tina46J44515