Задачата ни този път цели упражняване на познанията ни за HTTP, REST и JSON.
За разлика от предните задачи, този път няма да има автоматични референтни тестове, готови интерфейси, които да имплементирате или фиксирана от нас структура на проекта - имате цялата свобода, що се отнася до дизайна, имплементацията и тестването.
Създайте Java клиент, който предоставя възможност за търсене на рецепти за готвене по различни критерии.
REST API-то, което ще използваме за намиране на рецепти, е публично, има безплатен план и работи с application ID и application key като средство за автентикация, които може да вземете след регистрация. След приключване на работата по заданието, по желание можете да изтриете регистрацията си чрез изпращане на имейл до Edamam.
При регистрация, изберете план "Recipe Search API - Developer".
Необходимият ви endpoint e /api/recipes/v2, документиран тук.
Безплатният план на API-то има свои лимити - можете да правите до 10 заявки на минута, до 10000 заявки на месец и се връщат до 100 резултата на заявка, поради което ще се наложи да обмислите и оптимизирате използването му, докато разработвате и тествате.
Както казва чичото на Спайдърмен: "With Great Power Comes Great Responsibility". Този път, вие определяте абстракциите, които ще използвате. Използвайте възможността да приложите design patterns, като задачата предразполага в това отношение и съответно ще получите бонус.
Критериите, по които трябва да можем да търсим рецепти, са:
- ключови думи
- за кое хранене от деня е подходящо ястието (закуска/обяд/...)
- за какъв режим на хранене е подходящо (alcohol-free/gluten-free/...)
Уверете се, че клиентът поддържа търсене по различни комбинации от гореизброените параметри, като трябва да се поддържа подаване и на множество стойности за даден параметър.
От върнатите от API-то резултати, клиентът трябва да изчита като минимум следните полета за всяка готварска рецепта: label, dietLabels, healthLabels, totalWeight, cuisineType, mealType, dishType, ingredientLines.
Когато едно API може да върне голям брой резултати, обикновено (от performance съображения) то не го прави на един път, а използва т.нар. странициране - връща резултатите на части (страници), като първо извличаме първа страница, после втора и т.н.
Вътрешната имплементация на вашия Java клиент трябва да взима резултатите от поне две страници - вие решавате колко страници и по колко резултата максимум да вземете - единствено трябва да се съобразите с лимитите на безплатната версия на API-то.
При изпращане на заявка към сървъра, обработката ѝ не винаги е успешна. Когато нещо се обърка, сървърът връща подходящ статус код и съобщение, които следва да обработвате. Моделирайте тази функционалност с помощта на custom checked exceptions.
Сами отговаряте за цялостното тестване на решението си, ние пък ще оценяваме колко добре сте се справили с това. Целете се към висок code coverage, както и покрийте всички възможни сценарии, които вашият Java клиент поддържа, включително такива, които могат да ви се сторят тривиални. За постигане на висок code coverage, може да се наложи да използвате Mockito.
За да предадете решението си, архивирайте в zip архив src и test директориите на проекта и го качете в съответния assignment в грейдъра.