#asp.net-core #asp.net-core-mvc #asp.net-core-webapi #api-versioning #aspnet-api-versioning
#asp.net-core #asp.net-core-mvc #asp.net-core-webapi #api-управление версиями #aspnet-api-управление версиями
Вопрос:
В одной из наших существующих конечных точек .net core web api (REST) одним из значений его свойства в полезной нагрузке ответа является адрес электронной почты, который вскоре будет изменен на буквенно-цифровой идентификатор. Это изменение в полезной нагрузке ответа нарушит существующую интеграцию.
Это критическое влияние изменений можно устранить, введя версию в api, указав, что только версия v2 будет содержать буквенно-цифровой идентификатор в своей полезной нагрузке ответа, в противном случае версия v1 будет отображать адрес электронной почты в своей полезной нагрузке ответа, но есть ли какое-либо другое альтернативное решение, позволяющее избежать нарушения существующей интеграции даже после внесения изменений в существующую структуру полезной нагрузки ответа
Существующая структура полезной нагрузки ответа:
{
customerid: name@testdomain.com
}
Будущая структура полезной нагрузки ответа:
{
customerid: 1123acbd56
}
Комментарии:
1. Вы можете добавить необязательный параметр, чтобы включить изменение.
2. Извините за невежество, не могли бы вы объяснить немного подробнее с образцом, пожалуйста
3. В JSON нет типа данных для электронной почты или буквенно-цифровых значений. С точки зрения клиента, оба значения являются строковыми . Клиент никогда не должен предполагать что-либо о формате этих значений.
customerid!= электронная почта. Это проблема для клиента, если он это делает. Вам придется оценить, насколько важна попытка поддержать клиента, делающего это. Существует несколько возможных решений, некоторые из которых уже были предоставлены.4. пожалуйста, перечислите те несколько возможных решений, которые вы упомянули выше.
5. Для предоставления рекомендаций требуется некоторый дополнительный контекст, вот почему я не дал полного ответа. В самом строгом смысле, между и , как вы описали,
v1нетv2существенных изменений. Обе версии имеютcustomeridи обе имеют тип string. Однако, если один или несколько клиентов делают предположение о том, что это адрес электронной почты, это может быть проблемой. Это призыв к суждению. Это ничем не отличалось бы от того, если быcustomeridбыл GUID. В самом строгом смысле в контракте может быть указано только, что это строка.
Ответ №1:
Вы можете достичь этого, создав AcceptHeaderAttribute и передав Accept:[attrbute value]
Например, в приведенном ниже коде я создаю AcceptHeaderAttribute
[AttributeUsage(AttributeTargets.Method)]
public class AcceptHeaderAttribute : Attribute, IActionConstraint
{
private readonly string _acceptHeader;
public AcceptHeaderAttribute(string acceptHeader)
{
_acceptHeader = acceptHeader;
}
public int Order { get; set; }
public bool Accept(ActionConstraintContext context)
{
return context.RouteContext.HttpContext.Request.Headers["Accept"].Any(x => x.IndexOf(_acceptHeader) >= 0);
}
}
И вот в чем польза,
[HttpGet]
public User GetUserName()
{
return new User { Name = "Abcd" };
}
[HttpGet]
[AcceptHeader("app/vnd.user")]
public User GetUserEmail()
{
return new User { Name = "XYZ@ABCD.com" };
}
И вот ответ скрипача
Комментарии:
1. Следуя этой ссылке developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept . Заголовок Accept предназначен для указания типов MIME, таких как text / html, application / xhtml xml и т.д. Не нарушаем ли мы принцип здесь с приведенным выше примером? Кстати, app / vnd.user — это случайное значение или оно соответствует какому-либо стандарту / соглашению?
2. vnd предназначен для поставщика. это должно быть application / vnd.newuser. Чтобы сэкономить время, я написал app / vnd.user. Пожалуйста, ознакомьтесь с этой статьей: jacobbednarz.com/posts /…
3. Чтение вашей статьи проясняет несколько вещей. Но все же есть ли какая-либо причина, по которой вы предпочли заголовок «Принять» для выполнения этой проверки, а не вводить пользовательский заголовок, начинающийся с «X-«? Также по какой-либо причине «Принять» подход заголовка лучше, чем добавление queryparameter?
4. Ваш сценарий похож на управление версиями API. Управление версиями API может выполняться с помощью параметра запроса, заголовка пользовательского запроса, URL, заголовка accept. При использовании параметра запроса для таргетинга на определенную версию API в долгосрочной перспективе возникает путаница, поскольку параметр запроса никогда не сообщит вам, на какую версию API вы ориентируетесь, и вам может потребоваться проверить код api. Теперь конечная цель — не нарушать существующий клиент. Поэтому, как только вы вводите пользовательский заголовок, изменить заголовок не очень просто. Например, если вы введете x-new-user, в следующей версии вы не сможете сделать его x-first-user, поскольку это приведет к сбою существующих клиентов.
5. Вы будете создавать тесную связь с пользовательским ключом заголовка. При управлении версиями url api существующим клиентам также необходимо начать использовать новую структуру URL, если они используют неверсионную. В то время как заголовок Acept легче всего изменить в долгосрочной перспективе, что снижает затраты на тестирование.