Внутренний REST API - PullRequest
       20

Внутренний REST API

5 голосов
/ 29 января 2012

В настоящее время в нашей сети три сайта. Один написан на Ruby on Rails, а два других написаны на PHP. Все сайты имеют много общих данных и логику. Мне приходится повторять большую часть работы, которую я выполняю на стороне рельсов на стороне PHP. Похоже, нам нужен общий внутренний API для консолидации. Я никогда раньше не создавал API, и у меня есть несколько вопросов.

  • Производительность Если я создам API как отдельное приложение, кажется, что это будет в два раза медленнее. Поскольку он должен пройти весь цикл запросов / ответов в конце API, а затем снова на стороне общедоступного приложения. Есть ли способ сделать это быстрее? Или, может быть, другой подход?

  • Доступ к API через локальную сеть Как получить доступ к API через локальную сеть? Буду ли я устанавливать виртуальный хост в Apache, который указывает на 127.0.0.1?

  • Active Resource В моем случае (на конце рельсов) ActiveResource - лучший путь или есть лучшие варианты для использования API? Мне также интересно, как проверки будут работать на публичной стороне. Использует ли ActiveResource правила валидации или мне придется их пересоздавать на публичной стороне?

  • Безопасность API Я думаю, что сейчас мне не придется сильно беспокоиться об этом, поскольку доступ к API возможен (в идеале) только через локальную сеть. Я прав в этом предположении?

1 Ответ

2 голосов
/ 01 мая 2012

Есть целых книг , которые занимались этой конкретной темой.Работа с задержкой, стабильностью, гибкостью и всеми другими возможностями при создании сервисов.

С очень общей точки зрения и относительно простого варианта использования, который звучит так, как у вас, я бы порекомендовал простые API на основе REST в каждом приложении.Вы определенно не хотите повторять код в PHP, который уже написан на Ruby, и наоборот.Время отклика не слишком велико между конкурирующими методами запросов на основе HTTP (во всяком случае, не так резко, как при разговоре о чем-то вроде HTTP против CORBA).Написание REST-ресурсов - это то, в чем хорошо работает Ruby on Rails, так что у вас в значительной степени есть это.PHP немного сложнее, и вам просто нужно структурировать запрашиваемый API таким образом, чтобы он соответствовал стандартам REST.После этого вам просто нужен HTTP-клиент для выполнения запросов к любому клиенту.Если у вас есть четко определенные конечные точки для каждого приложения, это не должно быть большой проблемой, чтобы жестко их кодировать.Если нет, то существует еще один шаблон проектирования вокруг корпоративных сервисных шин , которые помогают одному сервису находить другой, но, как правило, не поддерживают кроссплатформенность (по крайней мере, не PHP по отношению к Rails и обратно)Что я знаю, то есть!).

Для мира Ruby / Rails я могу рекомендовать HTTParty или Typheous в качестве клиентов HTTP (которые будут запрашивать REST-клиент другого приложения).Что касается мира PHP, вы можете заглянуть в эту ветку .У него есть несколько перечисленных.

Для ясности, это не единственный вариант - вы можете создавать полнофункциональные веб-сервисы и даже углубляться, создавая прямые сокетные соединения, и др.На самом деле все зависит от того, насколько тесно вы хотите, чтобы системы были, насколько они могут быть тесно связаны, насколько они близки (в смысле «топологии сети») и насколько быстро реагирует каждая система.

Относительно безопасности. Один из вариантов - настроить брандмауэр в каждой системе так, чтобы он принимал подключения только к определенным ресурсам, если они имеют определенный IP-адрес.Вы можете следовать аналогичной схеме на уровне приложения.Хотя вам может быть так же повезло с безопасностью стандартного сеанса HTTPS с базовой / дайджест-аутентификацией.

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

...