Советы по дизайну веб-API

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

Затем я подумал, что смогу даже запустить сам веб-сайт через этот API по разным причинам, таким как более низкое потребление полосы пропускания (HTML генерируется в браузере) и кэширование на стороне клиента. Тяжелый AJAX казался еще большей причиной для этого.

Макет выглядит следующим образом:

Server (database, programming logic)
|
API (handles user reads/writes)
|
Client application (the website, browser extensions, desktop app, mobile apps)
|
Client cache (further reduces server reads)

После введения вот мои вопросы:

  1. Это хорошее использование API
  2. Стоит ли запускать весь сайт через API?
  3. Какие у меня есть варианты безопасной аутентификации с использованием API (по какой-то причине я предпочитаю не использовать HTTPS)

ИЗМЕНИТЬ

Дополнительный вопрос:

  1. Любые альтернативные подходы, которые я не рассматривал
  2. Какие потенциальные проблемы, которые я не учел, могут возникнуть при использовании этого подхода?

person Alexander Ivanov    schedule 12.08.2011    source источник


Ответы (2)


Перво-наперво.

Вопрос о том, является ли дизайн (или вообще что-либо) «хорошим», зависит от того, как вы определяете «хорошесть». Типичными критериями являются производительность, ремонтопригодность, масштабируемость, тестируемость, возможность повторного использования и т. д. Было бы полезно, если бы вы могли добавить что-то из этого контекста.

Было сказано, что...

Хорошее ли это использование API?

Обычно рекомендуется отделить бизнес-логику от логики представления и логики сохраняемости данных. Ваш дизайн делает это, и поэтому я был бы счастлив назвать его «хорошим». Вы можете посмотреть на формальный шаблон проектирования, чтобы сделать это - Контроллер представления модели, вероятно, является текущим значением по умолчанию, особенно. для веб-приложений.

Хорошо ли запускать весь веб-сайт через API?

Ну, это зависит от приложения. Вполне возможно написать приложение полностью на Javascript/Ajax, но есть проблемы с совместимостью браузеров (особенно для старых браузеров), и вам необходимо создать поддержку того, что пользователи обычно ожидают от веб-приложений, таких как глубокие ссылки и удобство для поисковых систем. Если у вас есть хорошо продуманный API, вы можете выполнять часть генерации страниц на сервере, если это упростит задачу.

Какие у меня есть варианты безопасной аутентификации с использованием API (по какой-то причине я предпочитаю не использовать HTTPS)

Хитрость — с таким приложением вы должны различать аутентификацию пользователя и аутентификацию приложения. В первом случае OpenID или OAuth, вероятно, являются доминирующими решениями; для последнего посмотрите, как Google требует от вас регистрации, чтобы использовать их API Карт.

В большинстве веб-приложений HTTPS используется не для аутентификации (доказательство того, что текущий пользователь является тем, кем он себя называет), а для шифрования. Они связаны, но ни в коем случае не эквивалентны...

Любые альтернативные подходы, которые я не рассматривал

Возможно, это больше подходит для вопроса 5, но, по моему опыту, проектирование API — это довольно эзотерический навык — разработчику API трудно точно предсказать, что понадобится клиенту API. Я бы серьезно подумал о том, чтобы написать приложение без API для вашей первой клиентской платформы, а затем исключить API — таким образом вы создадите только то, что вам нужно в первом выпуске.

Какие потенциальные проблемы, которые я не учла, могут возникнуть при использовании этого подхода

Управление версиями имеет большое значение для API: как только вы создали интерфейс, вы почти никогда не сможете его изменить, особенно если у вас есть несколько клиентов, которыми вы не управляете. Я бы встроил управление версиями в качестве первоклассной концепции — с RESTful API вы можете сделать это как часть URL-адреса.

person Neville Kuyt    schedule 22.08.2011
comment
Эй, спасибо за отличный ответ! Меня не интересуют старые браузеры и поисковые системы, так как весь веб-сайт представляет собой индекс с логином, и оттуда пользователи не видят информацию друг о друге (и, скорее всего, не захотят, чтобы их информация тоже была видна - особенно поисковые системы). Что касается аутентификации, меня в основном интересовало, как поддерживать идентификацию с пользователем. Я думал - пользователь входит в систему › сервер дает ему свой идентификатор сеанса › пользователь отправляет свой SID каждый раз, когда он связывается с сервером. Или, может быть, сервер отправляет какую-то строку, пользователь отвечает другой в соответствии с некоторыми правилами и так далее. - person Alexander Ivanov; 31.08.2011

  1. Это хорошее использование API

    Зависит от того, что вы будете делать с этим приложением.

  2. Стоит ли запускать весь сайт через API?

    нет, поэтому ваш сайт будет доступен только через ваше приложение. таким образом Эта реализация предотвращает совместимость с другими браузерами

  3. Какие у меня есть варианты безопасной аутентификации с использованием API (по какой-то причине я предпочитаю не использовать HTTPS)

    Вы можете использовать omniauth

  4. Любые альтернативные подходы, которые я не рассматривал

    создайте оба интерфейса, один в вашем приложении, а другой в обычных браузерах

  5. Какие потенциальные проблемы, которые я не учел, могут возникнуть при использовании этого подхода?

    Я не понимаю твоей идеи, но я не вижу серьезной опасности.

person Nicos Karalis    schedule 17.08.2011
comment
2. Как это проблема совместимости? Если я создам веб-приложение, совместимое с несколькими браузерами, через свой API, все должно быть в порядке. Вся моя идея состоит в том, чтобы обслуживать базовую страницу с парсером API, реализованным в JS, используя AJAX для запуска сайта. Таким образом, сайт не будет интегрирован с сервером, и если кому-то понравится, они смогут сделать сайт на своем сервере, который работает через мой API. Все дело в том, что этот подход все еще будет работать, если вы сохраните веб-страницу, а с кэшированием она может работать даже в автономном режиме. - person Alexander Ivanov; 17.08.2011
comment
3. Как еще я могу пройти аутентификацию? Я хотел бы сделать это на своем сервере и не использовать сторонние сервисы. - person Alexander Ivanov; 17.08.2011
comment
2. вы собираетесь создать только одну веб-страницу для управления любым запросом?? это не хорошо. если вы будете создавать каждую страницу с помощью ajax, почему бы вам не позволить пользователю вызывать эту страницу статически? ему легко (только один воркер для обработки) и вам (только один доступ к вашему серверу) - person Nicos Karalis; 17.08.2011
comment
3. OAuth не является сторонним, это шаблон проектирования для аутентификации, это отличный способ использования API. взгляните на аутентификацию в твиттере: у вас есть один токен и один токе-секрет, и сервер выполняет вычисления для аутентификации, я не могуt explain the oauth better, but it is better then plain authentication because you dont отправить пароль по почте или получить (ведь мы можем получить эти данные), и вы можете создать свой собственный аутентификация с использованием oauth в качестве базы. - person Nicos Karalis; 17.08.2011
comment
если вы все еще не пытаетесь использовать некоторые библиотеки, попробуйте реализовать это легко, и вы можете найти много полезных ссылок - person Nicos Karalis; 17.08.2011