Что необходимо учитывать при реализации пользовательского интерфейса RESTful в веб-приложении? - PullRequest
3 голосов
/ 31 мая 2011

В настоящее время я изучаю различные варианты создания не слишком сложного веб-приложения, в котором задействовано некоторое управление доступом на основе ролей.Кроме того, должны быть выполнены операции чтения / записи для небольшого числа (около 5) различных таблиц базы данных.

Я играл с идеей создания API на основе JSON, в котором один или несколькоФайлы PHP служат слоем поверх базы данных.Само веб-приложение будет полностью «статичным» HTML и javascript, использующим XHR для извлечения данных с сервера и, в конечном итоге, для обратной записи.Примером может служить текущая домашняя страница Twitter - при просмотре временной шкалы пользователя в исходном HTML-файле фактически не передаются твиты: все они извлекаются каким-то изящным javascript.

Один важный недостаток, который я вижу в этом, заключается в том, чточто роботу Google будет сложно проиндексировать этот вид веб-сайта.Некоторые компоненты приложения должны работать как обычный опубликованный контент, который может без проблем появляться в результатах поиска Google.Как, например, Twitter, добиться этого?Они обслуживают другую страницу, когда к их серверам обращаются веб-сканеры?

Кроме того, я хотел бы услышать некоторые мысли об этой концепции ... мне кажется, это очень интересный и чистый способотделяя бизнес-логику от представления, но, как всегда, я могу быть ужасно неправ: -)

1 Ответ

3 голосов
/ 31 мая 2011

Что ж, это глобальный вопрос, который требует большого ответа:)

Прежде всего, о вашем вопросе в Twitter, они используют стиль hashbang uri.Например, когда вы переходите на twitter.com / cx42net , вы автоматически перенаправляетесь на twitter.com / #! / Cx42net .

Когда это сканер, напримерGoogle боты, сканер изменит #! на ?_escaped_fragment=.Для твиттера это будет выглядеть так: http://twitter.com/?_escaped_fragment=/cx42net.

Я не буду вдаваться в подробности, чтобы избежать ошибок, хорошая ссылка предпочтительнее, поэтому здесь мы идем: SEOMoz: Как: Разрешить Google сканировать ваш AJAX-контент

Теперь для вашего веб-приложения в RESTful мне очень нравится идея отделения клиента от сервера, и я тоже пытаюсь работать таким же образом.

Вы говорите о доступе на основе ролей, что означает, что вам придется идентифицировать своих пользователей, чтобы разрешить / запретить доступ к определенной части вашего API.Существует две школы о том, как аутентифицировать пользователей с помощью API:

  • Школа «Использовать базовую аутентификацию HTTP»
  • Школа «Использовать аутентификацию / авторизацию OAuth»

Первый вариант очень прост в реализации, но я бы посоветовал вам сделать это через HTTPS, поскольку пароль передается в открытом виде по сети.

Последний вариант хорош, но гораздо сложнее реализовать.

Но на самом деле, это может быть именно то, что вы ищете, потому что, несмотря на аутентификацию вашего пользователя, вы можете предоставить им доступ к определенной части вашего API и ограничить их в какой-то другой части.Типичным примером является то, как Facebook / Twitter работают для этого, и я уверен, что вы уже разрешили сторонним приложениям использовать вашу учетную запись Twitter / Facebook.

Теперь использование OAuth обычно навязывает вам регистрацию/ таблица паролей хранится в вашей базе данных.Вы можете использовать OpenID, но это больше похоже на головную боль, чем на упрощение ваших пользователей: вам нужно аутентифицировать их у провайдера OpenId (например, Google), а затем перенаправить на свой API для предоставления доступа (если это первый раз), ТО перенаправить вашпользователя вашего приложения.

Наконец, я процитирую Фред Уилсон , 10 Золотых принципов успешного веб-приложения :

  • Скорость
  • Мгновенная утилита
  • Меньше значит больше
  • Сделайте его программируемым
  • Очистите
  • ...

Что ж, пока подойдет, если у меня появится другая идея, я отредактирую ответ и добавлю комментарий.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...