===== Получение лицформ =====
При создании подписки/подписчика может потребоваться отображать в UI лицформу со списком необходимых для заполнения полей (поля заполняются конечным пользователем). При этом:
  * поля могут быть разные для разных вендоров;
  * лицформы подписки для одного и того же вендора могут различаться по офферу;
  * поддержка переводов описаний полей, ошибок и пр.
===== Запрос ===== 

==== Синтаксис ==== 
^ Метод ^ URI ^ 
| GET | GET /license-form-rules?entity_type={entity_type}&offer_id={offer_id} | 
 
==== Параметры URI ==== 

^ Имя ^ Тип ^ Обязательный ^ Описание ^ Значение по-умолчанию ^
| entity_type | string | ✔ | Возможные значения: Subscription, Profile, Address | |
| offer_id | GUID | | ID продаваемой услуги (тарифный план) | |

==== Тело запроса ====
Нет.

==== Пример запроса ====
<code json>
GET /license-form-rules?subject=subscription&offer_id=c06b9b37-f449-4b6c-8e94-5da79b1ff4d5
GET /license-form-rules?subject=profile
GET /license-form-rules?subject=address
</code>
===== Ответ =====
{{page>vendor-api:response-success}}
**Тело ответа:** массив объектов ''LicenseFormRule''. У каждого правила поле ''Translations'' заполняется массивом переводов - массивом объектов ''LicenseFormTranslation'' (обязательно наличие хотя бы одного значения ''LicenseFormTranslation'').
\\ \\
Как заполнить MinLength/MaxLength, RegExp, AvailableValues. Если для выбранного в UI языка есть массив значений AvailableValues, то данные значения имеют максимальный приоритет, и проверки MinLength/MaxLength, RegExp **не выполняются**. Если в AvailableValues пусто, всегда выполняются 2 проверки: на RegExp и MinLength/MaxLength.
\\
^ Проверка ^ Когда проверяем ^ Текст ошибки (если значение поля не прошло проверку) ^
| AvailableValues | всегда, если есть значения в поле | поле AvailableValuesError |
| RegExp | если в AvailableValues пусто | поле RegExpError |
| MinLength/MaxLength | если в AvailableValues пусто | поле RegExpError |
//
//
** Лицформы и DynamicProperties **
Вендор может передать правила заполнения для поля, которого нет в контракте. В этом случае, поле будет отображаться в UI, но при отправке POST-запроса на создание объекта, название поля и введенное пользователем значение будут помещены в массив ''DynamicProperties'' в виде пары "ключ-значение". Пример см. ниже.
{{page>vendor-api:response-error}}

===== Пример ответа =====
<code json>
[{
    "EntityType": "Address",
    "PropertyName": "City",
    "MinLength": 10,
    "MaxLength": 20,
    "RegExp": "[aZaZa&9*]",
    "Required": true,
    "VisibleToEndUser": true,

    "Translations": 
    [{
        "LangCode": "RU",
        "Title": "Город",
        "Description": "Городок",

        "RegExpError": "Недопустимая длина поля / недопустимый символ",
        "AvailableValuesError": "Недопустимое значение",

        "LinkValue": null,
        "LinkTitle": null,
        "Commentary": null,
        "AvailableValues": ["City-17", "Данвич"]
    },
    {
        "LangCode": "EN",
        "Title": "City",
        "Description": "City",

        "RegExpError": "Incorrect field length / incorrect symbol",
        "AvailableValuesError": "Incorrect value",

        "LinkValue": null,
        "LinkTitle": null,
        "Commentary": null,
        "AvailableValues": ["City-17", "Dunwich"]
    }]
}]
</code>

===== Пример работы с DynamicProperties =====
Допустим, профиль пользователя имеет следующий контракт:
<code json>
Profile
{
    Id
}
</code>
Лицформа для профиля может содержать правило для поля Bar, этого поля в контракте нет:
<code json>
LicenseFormRule
{
    "EntityType": "Profile",
    "PropertyName": "Bar"
}
</code>
Вследствие этого, тело POST-запроса на создание объекта Profile будет выглядеть следующим образом:
<code json>
{
    "DynamicProperties": 
    [
        {
            Key: "Bar",
            Value: <user input>
        }
    ]
}
</code>
===== Контракт данных =====
{{page>vendor-api:contracts:license-form-rule}}
{{page>vendor-api:contracts:license-form-translation}}