Изграждане на RESTful API с Martini

.колапс "> Съдържание

Защо Мартини?

Друга ключова характеристика е, че след като Мартини ви изглежда „вълшебна“ (не харесвам магията), абсолютно трябва да погледнете нейния изходен код. то

400 реда код, малък на брой и добре контролиран (както беше тази сутрин), с една външна зависимост, инжекционният пакет, който е също толкова тънък, състоящ се само от

100 реда източник.

Моля, обърнете внимание, че в момента Мартини е в процес на активно разработване и че някои примери може да не работят, тъй като в него се правят промени. Ще се опитам да поддържам актуален изходния код на моите примери.

Нека опишем задачата

Примерното приложение ще осигури достъп до един ресурс, музикални албуми, по URI/албуми. И ще поддържа следната функционалност:

GET/албуми - списък на всички налични албуми, с възможно филтриране по изпълнител, заглавие или година, предаване на параметри в низа на заявката;
GET/албуми /: id - получаване на определен албум;
POST/албуми - създаване на албум;
PUT/албуми /: id - актуализация на албума;
ИЗТРИВАНЕ/албуми /: id - изтриване на албум.

За да направим нещата по-интересни, нека помислим, че отговорите могат да бъдат поискани в JSON, XML или обикновени текстови формати. Форматът на отговора ще бъде определен в края (чрез "разширение": .json, .xml или .text, по подразбиране JSON).

Тъй като изпълнението на подсистемата за съхранение на данни не е свързано с целта на създаването на приложението, ще използваме контролиран от mutex асоциативен масив от двойки ключ-стойност (приблизително Lane: в оригинал. "(Четене-запис) контролиран от mutex map "), която ще я използваме като база данни в паметта и ще я реализираме чрез следния интерфейс:

Нека дефинираме структура за съхраняване на данни от албуми като тази:

Сега нека видим как можете да използвате Мартини с това.

(приблизително платно - игра на думи „Dry Martini“ от една страна е препратка към името на известния сух вермут „Martini Extra Dry“, от друга страна е препратка към добре познатия принцип на разработка на софтуер DRY - Не се повтаряйте, докато думата "сухо" на английски означава "сухо")

Сърцето на пакета martini е типът martini.Martini, който реализира интерфейса http.Handler и следователно променливата тип martini.Martini може да бъде предадена на http.ListenAndServe () като най-често срещания манипулатор, очакван от стандартната библиотека. Друга важна концепция е, че Мартини използва подход, основан на множество слоеве междинен софтуер. Това означава, че можете да персонализирате списъка с функции, които да се извикват в определен ред, преди да бъде извикан манипулаторът, който обслужва конкретен URI. Това е много удобно за настройване на неща като регистриране, удостоверяване, управление на сесии и т.н. и ви позволява да запазите изходния код DRY (за който писах) DRY. Параграф по-горе).

За щастие, това е само удобна функция, винаги имаме опцията да създадем празен екземпляр на Martini и да го конфигурираме ръчно, ако е необходимо. Нашата версия изглежда така:

Нека засега да пропуснем междинния софтуер MapEncoder и да се върнем към него след минута. Следващата стъпка е да конфигурирате манипулаторите на URI. Martini предоставя хубав изчистен начин да направите това: поддържа етикети на параметри и освен това можете да използвате някои регулярни изрази.: Orig. "Можете дори да хвърлите някои регулярни изрази там, така ще завърши пътят така или иначе" ). Вторият параметър в Get/Post/Put/pr. е функцията манипулатор, която ще бъде извикана да обслужва дадения URI. Могат да бъдат зададени множество функции на манипулатора, които да обслужват един и същ URI. Всички те ще се изпълняват на свой ред. Извикването им в тази опашка ще бъде прекратено веднага щом някой от тях отговори на заявката (приблизително трансл.: Orig. "(Това е вариадичен параметър) и те ще бъдат изпълнени по ред, докато някой от тях напише отговор ").