Как уже указывал С.Лотт, у нас есть две сложенные вещи: логин и аутентификация
Аутентификация здесь выходит за рамки, так как это широко обсуждается и существует общее согласие. Тем не менее, что нам на самом деле нужно, чтобы клиент успешно прошел аутентификацию на веб-службе RESTful? Хорошо, какой-то токен, назовем его токен доступа.
Клиент) Итак, все, что мне нужно, это токен доступа, но как получить такой RESTful?
Сервер) Почему бы просто не создать его?
Клиент) Как получается?
Сервер) Для меня токен доступа - это не что иное, как ресурс. Таким образом, я создам его для вас в обмен на ваше имя пользователя и пароль.
Таким образом, сервер может предложить URL-адрес ресурса "/ accesstokens", для отправки имени пользователя и пароля, вернув ссылку на вновь созданный ресурс "/ accesstokens / {accesstoken}".
В качестве альтернативы вы возвращаете документ, содержащий токен доступа и ссылку со ссылкой на ресурс:
<access-token
id="{access token id goes here; e.g. GUID}"
href="/accesstokens/{id}"
/>
Скорее всего, вы на самом деле не создаете токен доступа как подресурс и, следовательно, не будете включать его href в ответ.
Однако, если вы это сделаете, клиент может сгенерировать ссылку от своего имени или нет? Нет!
Помните, что действительно веб-сервисы RESTful объединяют ресурсы таким образом, чтобы клиент мог самостоятельно перемещаться без необходимости создавать какие-либо ссылки на ресурсы.
Последний вопрос, который у вас, вероятно, возникнет, заключается в том, следует ли вы ПОСТАВИТЬ имя пользователя и пароль в виде HTML-формы или в виде документа, например, XML или JSON - это зависит ...: -)