Навіщо використовувати веб-сервіси замість прямого доступу до реляційної бази даних для програми Android?

Я шукав в Інтернеті, як ефективно отримувати доступ до центральної бази даних у віддаленому місці, і зустрічав пропозиції щодо використання веб-служб замість прямого доступу (наприклад, JDBC тощо) до бази даних. Цікаво, чому причина та будь-які інші пропозиції .

Додавання рівня веб-сервісу дає можливість зробити клієнта більш легким, як з точки зору необхідної потужності процесора, так і пропускної здатності, що використовується під час обробки. Обидва фактори є надзвичайно важливими для кінцевих споживачів:

• Використання менше процесора збільшує час автономної роботи,
• Використання меншої пропускної здатності зменшує щомісячні платежі для користувачів з дозованими планами

Вводячи рівень веб-додатків, ви переміщуєте основну частину обробки з мобільного мобільного пристрою малої потужності, низької пропускної здатності, клієнта з низькою пам’яттю на підключений, високопотужний широкополосний сервер, який має більше пам'яті потреби - середовище, коли обробка та комунікації коштують частину того, що вони коштують клієнту.

Але зачекайте, в цьому є щось і для вас: розділяючи систему, ви отримуєте більше контролю над правилами вашого бізнесу, структурою вашої бази даних та версіями того, що там є. Після того, як ви дозволите мобільному клієнту підключитися безпосередньо до бази даних, ваш дизайн "одружений" із цією структурою бази даних: практично будь-які зміни можуть порушити сумісність з клієнтом, який може неохоче оновити його додаток.

На відміну від цього, додавання між собою веб-сервісу дозволяє розвивати інтерфейс для мобільних клієнтів більш керованими способами: наприклад, ви можете тримати старий інтерфейс на місці, додати новий, який працює «паралельно» з ним, а потім цілком реструктуруйте вашу базу даних, не порушуючи жодного клієнта.

Якщо дотримуватися деяких досить основних принципів дизайну при розробці веб-сервісу, ви також можете отримати значні переваги, скориставшись застосованою зрілою інфраструктурою на сервері: наприклад, ви можете безкоштовно отримати кеш-послуги та проксі-сервіси.

Нарешті, це відкриє двері для інших розробників, які піддаватимуть ваш додаток платформам, які ви не могли обслуговувати самостійно, зрештою, граючи на користь своєї компанії.

Він ставить шар абстракції між додатком та БД. Це дає безліч переваг, таких як:

• Обмеження доступу до БД лише частинами, які потрібні додатку. Це і спрощує код програми, і захищає вашу БД.
• Розглядає внутрішню роботу БД, тому, якщо ви пізніше вирішили змінити схему, запити чи навіть всю свою базу даних, посилання на ваш додаток не буде порушено, якщо ви правильно підтримуєте середній рівень.
• Це дозволяє додавати функціональність поза рамками БД. Наприклад, дані про кешування досить постійні. Правила ведення бізнесу - це ще одна частина, яка повинна бути окремо від БД.

Ще одна причина, щоб не виставляти БД безпосередньо - транспорт. Більшість реляційних баз даних, такі речі, з якими можна спілкуватися з JDBC, загалом не розроблені для загальнодоступного Інтернету. Бездротовий Інтернет - це жахливо ненадійний кінець згаданого публічного Інтернету. Поводження з винятками було б кошмарним, і ви, ймовірно, закінчилися писати реверс шару веб-служб всередині додатка, щоб уникнути втрати транзакцій.

Існує кілька нових типів баз даних, які розмовляють HTTP і можуть бути придатними для подібних речей. Вони також схильні показувати способи розміщення коду додатків у базі даних. Ви можете поглянути на CouchDb або RavenDb - і те, і інше, є dbs-документами з можливостями картографування / зменшення, що працюють над json та http, як і багато сучасних веб-сервісів.