Я создаю веб-приложение, которое будет управлять несколькими сайтами моих клиентов. Он также включает в себя API для отдыха. Было бы разумно, если бы PHP-сайты моих клиентов использовали curl, чтобы использовать API вместо прямого вызова кода PHP, который у меня есть. Мне сказали, что это облегчит развертывание, особенно для клиентов, чьи веб-сайты не находятся на моем сервере, но я не вижу в этом преимущества. Также мне сказали, что это поможет защитить наш код, опять же я не вижу преимуществ этого, поскольку клиент будет иметь доступ только к базовым моделям активной записи. У меня нет проблем с использованием завитка. Моя проблема заключается в том, что на данный момент все сайты моих клиентов размещены на моем сервере, я не думаю, что эффективно иметь запрос, поступающий на сервер, только для того, чтобы сервер отправил запрос на завиток для заполнения этого запроса. Любое мнение очень ценится.Должен ли я использовать завиток, чтобы потреблять мою собственную апи?
ответ
Я думаю, что это прекрасная модель, даже если вы получаете накладные расходы на вызов PHP дважды. Это накладные расходы реальны!
Однако, один из вариантов заключается в том, что если ваш API работает хорошо, и вы правильно построили его с объектами запроса/ответа (вместо того, чтобы полагаться непосредственно на глобалы, суперглобалы, php: // input, header() и т. Д.), Тогда вы также может создать «поддельный HTTP-клиент», который просто вызывает тот же PHP-код локально.
По существу, сайты моих клиентов должны иметь возможность использовать локальный код, и если он недоступен, он вызывает API? –
Нет, я говорю, что с точки зрения веб-сайта клиента он должен выглядеть и выглядеть как HTTP-запрос, тогда как на самом деле вы издеваетесь над объектами запроса/ответа, которые «притворяются», чтобы сделать HTTP-запрос, но на самом деле настроили ваш источник API и выполните локальный вызов. – Evert
Если это не имеет никакого смысла для вас, просто делайте реальные HTTP-запросы и комментируйте здесь через год, когда у вас возникают проблемы с производительностью;) – Evert
Совершенно прекрасно создавать систему, в которой вы также потребляете свой собственный API. Такое решение является масштабируемым и гарантирует, что потенциальные клиенты будут использовать стандартизованный API, который вы также используете. Однако, как вы могли заметить, это скорее вопрос дизайна, а не прямой вопрос программирования, поэтому он может быть закрыт из-за того, что он оффтопик. –
Аналогичные Programmers.SE: [Должен ли я использовать свой собственный публичный API для моего веб-интерфейса?] (Http://programmers.stackexchange.com/questions/302028/should-i-use-my-own-public-api-for -my-web-интерфейс) – HPierce
Curl - это хорошо, что может быть еще лучше - предоставить вашим клиентам библиотеку-обертку вокруг вызовов API. Таким образом, пользователям не нужно знать о механике API, и если вам когда-либо придется вносить изменения, вы можете обновить оболочку, а не все клиенты, изменившие код, зависящий от вашего API. –