Díky za video. My používáme v interních API knihovnu Sieve od Biarity, která tu byla zmíněná. Ta se stará o převod query filtru/sort/pagination na EF Linq. Filter query parametr pak vypadá např: filters=Number==123,name@=cokoliv. Kde == znamená striktní equals a @= znamená contains atp. Je to hodně benevolentní a zároveň téměř bezpracné, tak jak filters query přijde tak se dá předat Sievu a ten sestatví Linq query, ale chápu že ve veřejném API by to mohlo způsobovat problémy. A rozhodně považuji za užitečnou radu funkcionalitu minimalizovat jen na to nezbytné.
Jak pak doporučujete resit implementaci pro jednotlivé endpointy? Mate na to nejakou svoji nebo doporucovanou knihovnu, ktera vsechno tohle resi, nebo pisete vždy na míru pro každý endpoint? A Diky za videa 👍
Pro query filters stačí udělat pár tříd. Nad každou si lze udělat validátor a na vhodném místě ji pak použít v dotazování. Nepřijde mi to jako tolik práce pro extra package. Když je to rozhraní jednoduché, je to snazší než konfigurovat extra knihovnu, protože se tím ztratí dost času. U složitějšího rozhraní už by něco použít šlo (sám nic vlastního opakovaně nepoužívám). Ale je otázka, jestli je složité rozhraní s komplexními filtry dobré rozhraní :)
Díky za video. My používáme v interních API knihovnu Sieve od Biarity, která tu byla zmíněná. Ta se stará o převod query filtru/sort/pagination na EF Linq. Filter query parametr pak vypadá např: filters=Number==123,name@=cokoliv. Kde == znamená striktní equals a @= znamená contains atp. Je to hodně benevolentní a zároveň téměř bezpracné, tak jak filters query přijde tak se dá předat Sievu a ten sestatví Linq query, ale chápu že ve veřejném API by to mohlo způsobovat problémy. A rozhodně považuji za užitečnou radu funkcionalitu minimalizovat jen na to nezbytné.
Jak pak doporučujete resit implementaci pro jednotlivé endpointy? Mate na to nejakou svoji nebo doporucovanou knihovnu, ktera vsechno tohle resi, nebo pisete vždy na míru pro každý endpoint? A Diky za videa 👍
Pro query filters stačí udělat pár tříd. Nad každou si lze udělat validátor a na vhodném místě ji pak použít v dotazování. Nepřijde mi to jako tolik práce pro extra package. Když je to rozhraní jednoduché, je to snazší než konfigurovat extra knihovnu, protože se tím ztratí dost času. U složitějšího rozhraní už by něco použít šlo (sám nic vlastního opakovaně nepoužívám). Ale je otázka, jestli je složité rozhraní s komplexními filtry dobré rozhraní :)