REST API Совместное проектирование двух ресурсов
Как сделать API как /account/login в консоли metamug. Ресурс аккаунта у меня уже есть. Но я хочу, чтобы с его помощью был доступен вход в систему.
Поскольку метамуг не позволяет использовать два ресурса вместе, как я могу этого добиться?
Это позволит /account/123/login, но я этого не хочу.
Ответы 1
Согласно архитектурному стилю REST, /account/123/login - правильная реализация.
Metamug следует стилю и не допускает последовательных ресурсов на пути.
Единственный способ заставить этот URL работать - рассматривать логин как идентификатор. Таким образом, это становится Запрос на предмет.
Это запрос на вход, мы будем использовать метод POST.
<Request method = "POST" item = "true">
<Query when = "$id eq login">
select userid from user where username = $user
and password = $pass
<Query>
</Request>
Дальнейшее чтение. https://martinfowler.com/articles/richardsonMaturityModel.html
Спецификации изложены Роем Филдингом. Люди, которые не следят за ними, должны это посмотреть. youtube.com/watch?v=nSKp2StlS6s
REST - это не протокол, а просто архитектурный стиль, который при последовательном соблюдении помогает в отделении клиентов от серверов, полагаясь на промежуточный тип носителя, с которым согласны обе стороны, используя ссылки для ссылки на другие ресурсы и давая им осмысленные имена (HATEOAS) вместо принуждение клиентов к синтаксическому анализу URI и интерпретации его семантики, а также использование семантики базового транспортного протокола для повышения совместимости. Выполнение чего-либо другого просто приведет к пути к RPC-подобному API, который с уверенностью сломает клиентов при изменениях этого API.
@Sorter Не могли бы вы дать ссылку на спецификацию, изложенную Роем Филдингом, которая требует /account/123/login?
Кстати, я думаю, что модель зрелости Ричардсона сильно переоценена, особенно с точки зрения REST. Во-первых, должен быть установлен уровень 3, и даже при включенном уровне 3 это не гарантия того, что используемая в результате архитектура следует принципам REST, подумайте о создании не на общих специализированных типах мультимедиа, а о настраиваемых сообщениях application / json. Клиент должен иметь некоторые априорные знания о данных, которые он получает, и потерпит неудачу, если сервер когда-либо отправит что-то другое.
@VasiliyFaronov вот его твиттер twitter.com/fielding, почему бы не спросить его. Кстати, в своей биографии он заявляет, что стандартизировал URI. Я думаю, это то, что вы ищете.
@Sorter Нет, он стандартизировал общий синтаксис URI. Его REST диссертация не имеет требований к внутренней структуре URL-адресов. Утверждение вашего ответа о «спецификациях» неверно.
Он также принимал участие в стандартизации HTTP, PATCH и прочего, но какое это имеет отношение к фактическому вопросу @VasiliyFaronov? URI в REST на самом деле не обязательно должны быть красивыми или понятными для человека, поскольку клиенты должны определять свои намерения по имени отношения и не анализировать какую-либо семантику из токенов URL. Имя отношения может быть чем-то простым, например prev, next, self, first, last, ... и они могут быть стандартизированы другими протоколами или определены в самих типах носителей.
@VasiliyFaronov Я много поискал и согласен с вами. Обновил свой ответ. Я не смог найти ни одного RFC, в котором были бы указаны спецификации. Это просто архитектурный стиль. Спасибо за полезное обсуждение.
Однако "это реализация верное" слишком силен. Я бы сказал, что это действительный URI.
@Sorter Спасибо за ваши усилия, но ваш обновленный текст все еще не отражает сути. Архитектурный стиль REST, как определено Филдингом, не требует структуры URL-адресов. Вся суть REST Филдинга в том, чтобы отделить сервер от клиента. /_content/api.dll?ENTITY=account&ID=123 - отличный URL в REST Филдинга, если сервер явно передает его клиенту в виде гиперссылки.
Что такое «спецификации REST»?