¿Por qué no debería dar acceso a personas de afuera a mi base de datos?

Question

Muchos de los sitios actuales tienen API que permiten a los usuarios obtener datos del sitio como XML o JSON utilizando una solicitud GET HTTP. Flickr y del.icio.us son ejemplos de sitios con API. Estas API requieren que el servidor acceda a la base de datos, y luego generan el resultado como XML o JSON.

¿Por qué necesitamos esta traducción sin embargo? ¿Por qué no simplemente crear un usuario en la base de datos (por ejemplo, MySQL)? El usuario tendrá acceso limitado a la base de datos, solo se le permitirá SELECCIONAR, y solo ciertas tablas y ciertas columnas en esas tablas. ¿No sería esto mucho más eficiente para el servidor (no tendría que lidiar con la solicitud HTTP), y sería más fácil para los desarrolladores, que ahora podrían acceder exactamente a los datos que necesitan, de la manera que lo necesitan.

Answer 1

Las consideraciones de seguridad a un lado, por lo que puede cambiar la estructura de su base de datos sin afectar a sus clientes. Además, las consultas mal formadas atan su servidor, no a los clientes.

Answer 2

se puede prevenir una persona malintencionada de la elaboración de una consulta SQL súper compleja que la clavija de la CPU de su base de datos al 100%? ¿Puede evitar que muchos programadores inocentes elaboren consultas ineficaces que nunca se optimizarán y que harán lo mismo?

Answer 3

el servidor web le proporciona un búfer que puede controlar. si hay algún error en su servidor sql o lo que sea, no quiere que se exponga directamente a internet. es cierto, si el servidor web tiene errores, podría ser igual de malo ... excepto que tienes esa capa adicional entre los datos y el mundo.

-don

Answer 4

Portabilidad también. Digamos que por razones de licencia y escalamiento, usted toma la decisión comercial de pasar de MSSQL a MySql. La sintaxis no es la misma y tus clientes deberán cambiar su código.

Mucho mejor que acaba de búfer si fuera poco y mantener la implementación abstraído. ¿De quién decir que no está persistiendo en el estado de la aplicación usando monos entrenados arañando marcas en las tapas de botellas?

Answer 5

No es tanto una cuestión '¿por qué no' que un '¿para qué'. El manejo de las solicitudes HTTP es una pequeña penalización para tener un control completo sobre a qué información le permite o no permite el acceso de un usuario. Además, si el nivel de cantidad/seguridad/naturaleza de los datos cambia en el futuro, estará mejor con una respuesta JSON/XML que permitiendo el acceso total.

Answer 6

Una API:

• Hace que sea más fácil de Montior y el uso de control (ejecución 'consultas limitadas por X' para los usuarios de base de datos puede ser más difícil)
• Permite presentar estructuras más sencillas para el usuario que puede ser utilizado en el DB.
• Significa que el usuario no tiene que entender su estructura de base de datos.
• Permite la portabilidad de DB. (Oh, has crecido masiva y ahora que poner en práctica: sharding, mover a Bigtable, etc. - Con una API que el usuario no necesita saber)
• permite diferentes de almacenamiento en caché de solicitudes (mejor/variable??) .
• Significa que no tiene que pagar por los usuarios DB adicionales (si así es como se licencia la base de datos).)

Answer 7

Codificación a contrato - con las API, puede cambiar todo detrás de ellos sin afectar a personas ajenas uso de ellos. Aquí tendría que estar atando a no sólo MySQL, pero su esquema

almacenamiento en caché - Permitir que cualquier consulta casi elimina cualquier oportunidad para el almacenamiento en caché que las consultas predecibles a través de HTTP que se pueden utilizar. Esta es probablemente la forma principal de eliminar el cuello de botella a menudo número uno, la base de datos.

Seguridad - con este enfoque, sería fácil para un ataque de denegación de servicio, incluso por accidente. Sin mencionar el hecho de que tendrías que dar acceso a la capa de datos, que a menudo se pone en una zona restringida donde se puede ajustar la seguridad

Usabilidad - no todo el mundo es desarrollador o quiere entender un dominio interno . Probablemente prefieran una API predefinida y autoexplicativa. Un ejemplo extremo sería dar a los administradores privilegios de db en lugar de informes.

Answer 8

API es un tipo de Wrapper alrededor de la base de datos. Los usuarios no saben nada sobre la representación interna de datos de la base de datos, solo necesita enviar un número de solicitudes unificadas y obtener una respuesta unificada en él. Cómo y cuándo se procesarán los datos en el servidor; no es su dolor de cabeza.

Answer 9

La seguridad es el motivo número 1, pero espero que esas razones sean obvias. El usuario que bloquea recursos valiosos con malas consultas es otra buena razón.

Más allá de eso, ¿por qué una capa de abstracción?

• ¿Alguna vez desea agregar algo de registro a las consultas de la base de datos para diagnosticar la velocidad o ayudar a depurar?
• ¿Alguna vez podría pasar de MySQL a MS SQL o viceversa donde podría romper SQL que no sea puro ANSI?
• ¿El cliente realmente debe aprender su esquema en lugar de una abstracción más lógica?
• Cuando un nuevo programador se entera de la normalización y ahora puede ver su esquema completo, incluidas sus desnormalizaciones cuidadosamente equilibradas, ¿quiere soportar todas las críticas desinformadas?
• Cuando una persona con experiencia en db señala mejoras, ¿quiere quedarse con su viejo esquema?

Por qué usar una API es una pregunta de por qué usar abstracciones y mi lista aquí apenas araña la superficie.

Answer 10

Lo que debe tener en cuenta cuando piensa en problemas de seguridad es que es realmente difícil para anticipar todos los posibles vectores que alguien podría usar para atacarlo. Por ejemplo, ¿está realmente seguro que ha configurado los permisos de su base de datos para que las personas no puedan estropear las cosas?

Por lo tanto, debe intentar restringir las acciones solo a lo que sabe que es bueno, no solo tratar de restringir las cosas que sabe que son malas. Esto se puede hacer con un servicio web sobre el que tenga control absoluto, pero es difícil permitir que alguien acceda directamente a la base de datos y asegurarse de que esté seguro.