Бърза версия:
Използвайте междинен слой на уеб услуга, работещ на публичен хост, който контролирате (възможно е, но не непременно хостът на базата данни). Разкрийте методите на публична уеб услуга за извършване на ограничената работа, която искате да разрешите и нищо друго.
Свързани въпроси:
Опции за внедряване
Лично аз бих използвал сървър за приложения на Java като Apache Tomcat или JBoss AS 7 и бих написал методите си за уеб услуги, използвайки JAX-RS за създаване на хубав API в стил REST, който да използва моето приложение. Това е, с което съм запознат и работи добре, но имате много опции, включително реализации на:
-
Подобни на REST API (JAX-RS на Java включва Jersey и RESTEasy, различни други езични инструменти), които използват HTTP заявки и произвеждат JSON или XML отговори.
-
SOAP с WSDL, класическият слой "уеб услуга". В Java, направено с JAX-WS наред с други опции. Повечето езици имат инструменти за SOAP+WSDL, но работата с тях е доста скапана, особено на периодично свързани устройства като мобилни телефони.
-
XML-RPC, ако обичате болка
Има някои JAX-RS бързи стартове на JBoss AS 7 бърз старт списък; просто потърсете "JAX-RS". „кухненска мивка " бързият старт е полезен, макар че може би не е идеален, ако не сте запознати с основите на JBoss AS 7 и Jave EE 6. За спецификата на JAX-RS е по-добре с Jersey или RESTEasy урок като това или това .
Важни съображения
Използвайте HTTPs, ако е възможно, и ако достъпът не трябва да бъде публичен, използвайте подходяща схема за HTTP удостоверяване като HTTP Basic auth през HTTPs. Всяка прилична реализация на уеб услуги ще предлага опции за удостоверяване или ще поддържа тези на платформата, на която работи. Избягвайте изкушението да внедрите свое собствено удостоверяване и управление на потребителите на слоя на уеб услугите, вие ще прецака го; използвайте удостоверяването на HTTP слоя, който вече е написан и тестван. Това може да изисква използването на нещо като mod_auth_pgsql на Apache , областите за сигурност JDBC на JBoss AS 7 и т.н. Единственият случай, който бих обмислил да не правя правилно HTTP удостоверяване за всеки потребител, е когато не е необходимо да разделям потребителите си от съображения за сигурност, интересува ме само това, че моето приложение има достъп до сървъра , т.е. ако изискванията ми за сигурност са доста слаби. В този случай бих използвал фиксирано потребителско име/парола за цялото приложение и евентуално клиентски сертификат X.509, ако Android ги поддържа.
Не забравяйте, че без значение как защитавате нещата, всички идентификационни данни са или известни на потребителя, или могат да бъдат извлечени тривиално от .apk, така че все още трябва да приемете, че всеки може да има достъп до методите на вашата уеб услуга, не само вашето приложение. Напишете ги съответно.
Не просто изпратете SQL от вашето приложение чрез извикване на уеб услуга към сървъра и върнете резултатите като JSON. Това е ужасяващо несигурно, както и грозно и тромаво. Напишете метод за уеб услуга за всяка отделна задача, която искате приложението да може да изпълнява, и запазете SQL в сървъра. Не забравяйте да използвате параметризирани заявки и внимавайте за други рискове от инжектиране на SQL. Тези методи на уеб услуга могат да използват една или повече заявки, за да произведат един отговор - например можете да съберете запис „Клиент“ и всички свързани записи „Адрес“ и „Контакт“, след което да върнете резултата в хубав JSON обект на устройството с Android може да консумира, спестявайки множество бавни и ненадеждни мрежови двупосочни пътувания.
Без значение какво използвате, уверете се, че извършвате извикванията на уеб услугата във фонова работна нишка и не блокирайте потребителския интерфейс. Бъдете готови за изчакване и грешки, както и за необходимостта от повторни опити. Тествайте приложението си, като симулирате периодична загуба на връзка, висока латентност и високи нива на загуба на пакети и се уверете, че остава използваемо.
