Update 2 files

- /README.md
- /API.md

API.md

@@ -0,0 +1,21 @@
+#API
+
+Это документация по стандартизации разрабатываемой api. Нужна для того, чтобы не возникало вопросов по тому, какой интерфейс должен быть
+
+##Общие положения
+
+- По умолчанию используем REST
+- Общение между сервисами организуется через grpс. Если нужно получить какую-то информацию от внутреннего сервиса, идём в этот сервис и делаем метод для этого.
+- Методы которые используются админами и методы которые используются клиентами надо разделять на 2 раздельных сервера
+- Иногда может понадобится стрим данных. SSE в приоритете, но если требуется изменение свойств стрима или запросов очень много и есть возможность перевести весь фронтенд перевести на другую технологию, берём вебсокет. Возможно потом попробуем wormhole
+- Роут метода должен формироваться следующим образом: /{название сущности}[/{идентификатор сущности, если работа с конкретной сущностью}]/[дополнительное указание метода, если REST метода недостаточно]
+
+##Получение данных
+
+### Получение списка сущностей с пагинацией
+
+- Дополнительное указание метода чаще всего нужно. Для единообразия стоит указывать getList
+- REST метод GET
+- Стандартные GET параметры для запроса page - указание номера страницы выборки и size - для указания размера страницы
+- В ответе должны быть: массив запрашиваемых сущностей и количество сущностей по этому фильтру вообще
+- Позднее будет введена логика фильтров. Как их будем передавать я пока не знаю. Явно через GET параметры, но как json или через какую-то логику саб параметров - не знаю

README.md

@@ -26,6 +26,12 @@
 
 - контекст всегда передавать вне структуры с зависимостями
 
+- Клиенты к сервису располагать рядом с сервисом, в каталоге /pkg/client
+
+- Стандартные сокращения: err, ctx, resp, deps, opts
+
+- Ресиверы сокращать до первой буквы названия типа. НИЧЕГО другого до одной буквы не сокращать.
+
 ## Рассматриваемое
 
 - Именование: одно и то же именование не должно соответствовать концептуально разным сущностям. Пример называть все ошибки err нормально, пока они выполняют одну и ту же роль - единственной возвращаемой ошибки, но называть разные ресиверы одним именем вредно
@@ -36,14 +42,8 @@
 
 ## Предложение
 
-- Стандартные сокращения: err, ctx, resp, deps, opts
-
-- Ресиверы сокращать до первой буквы названия типа. НИЧЕГО другого до одной буквы не сокращать.
-
 - Есть мысль, помечать внутрненние пакеты суффиксом или префиксом, чтобы при чтении кода быстро определять, что есть что. но она требует рассмотрения на практике
 
 - Отделять переносами строки разнотипные операции - штука верная, но без фанатизма. Отделять ли объявление переменных от блока кода, в котором они будут использоваться - дело каждого
 
 - Разбиение на файлы: не вижу технического смысла выносить в отдельный файл сущность, которая чисто техническая и используется только в рамках другой сущности, как например конфиг для приложения, структуры запросов, возвращаемых значений, утилиты, используемые одним пакетом и тому подобное
-
-- Клиенты к сервису располагать рядом с сервисом, в каталоге /pkg/client