Почему я не должен предоставлять доступ посторонних к своей базе данных?

Можете ли вы предотвратить создание злоумышленником сверхсложного SQL-запроса, который на 100% загрузит процессор вашей базы данных? Можете ли вы помешать многим невинным программистам создавать неэффективные запросы, которые никогда не будут оптимизированы, которые будут делать то же самое?

API:

• Облегчает мониторинг и контроль использования (реализация «ограниченных запросов на X» для пользователей БД может быть сложнее)
• Позволяет представлять пользователю более простые структуры чем можно использовать в БД.
• Означает, что пользователю не обязательно понимать структуру вашей БД.
• Обеспечивает переносимость БД. (О, вы сильно выросли, и теперь вам нужно реализовать: сегментирование, переход на bigtable и т. Д. - с помощью API пользователю не нужно знать)
• Позволяет использовать другое (лучше? / Переменную?) Кеширование запросов .
• Означает, что вам не нужно платить за дополнительных пользователей БД (если так лицензируется БД.)

Кодирование для контракта - с помощью API вы можете изменить все, что стоит за ними, не влияя на их использование посторонними. Здесь вы бы связали их не только с MySQL, но и с вашей схемой

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

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

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

Безопасность - это причина номер 1, но я надеюсь, что эти причины очевидны. Еще одна веская причина - это то, что пользователь связывает драгоценные ресурсы с помощью неверных запросов.

Кроме того,

Также переносимость. Допустим, по причинам лицензирования и масштабирования вы принимаете бизнес-решение о переходе с MSSQL на MySql. Синтаксис не совсем тот же, и всем вашим клиентам придется изменить свой код.

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

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

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

-don

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

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

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