Rychlá verze:
Použijte mezivrstvu webové služby běžící na veřejném hostiteli, který ovládáte (možná, ale ne nutně na hostiteli databáze). Vystavte metody veřejné webové služby, abyste dělali omezenou práci, kterou chcete povolit, a nic jiného.
Související otázky:
Možnosti implementace
Osobně bych použil aplikační server Java jako Apache Tomcat nebo JBoss AS 7 a své metody webových služeb bych napsal pomocí JAX-RS vytvořit pěkné API ve stylu REST, které bude moje aplikace používat. To je to, co znám a funguje to dobře, ale máte spoustu možností včetně implementací:
-
Rozhraní API podobná REST (JAX-RS od Java zahrnuje Jersey a RESTEasy, různé další jazykové nástroje), které používají požadavky HTTP a vytvářejí odpovědi JSON nebo XML.
-
SOAP s WSDL, klasickou vrstvou „webové služby“. V Javě provedené mimo jiné pomocí JAX-WS. Většina jazyků má nástroje pro SOAP+WSDL, ale práce s nimi je poněkud mizerná, zejména na přerušovaně připojených zařízeních, jako jsou mobily.
-
XML-RPC, pokud máte rádi bolest
Existuje několik JAX-RS rychlé starty na rychlé starty JBoss AS 7 seznam; stačí vyhledat "JAX-RS". The " " rychlý start je užitečný, i když možná není ideální, pokud nejste obeznámeni se základy JBoss AS 7 a Jave EE 6. Pro specifika JAX-RS je lepší použít Jersey nebo RESTEasy tutoriál jako toto nebo toto .
Důležité úvahy
Pokud je to možné, používejte protokoly HTTP a pokud přístup nemá být veřejný, použijte vhodné schéma ověřování HTTP, jako je základní autentizace HTTP přes HTTPs. Každá slušná implementace webových služeb nabídne možnosti autentizace nebo bude podporovat možnosti platformy, na které běží. Vyhněte se pokušení implementovat vlastní ověřování a správu uživatelů ve vrstvě webových služeb, budete pokazit to; použijte auth na vrstvě HTTP, která je již napsána a otestována. To může vyžadovat použití něčeho jako Apache mod_auth_pgsql , bezpečnostní sféry JDBC JBoss AS 7 atd. Jediný případ, který bych považoval za neprovedení správného ověření HTTP pro jednotlivé uživatele, je ten, kdy z bezpečnostních důvodů nepotřebuji oddělovat své uživatele, záleží mi pouze na tom, aby k serveru přistupovala moje aplikace. , tedy pokud jsou moje bezpečnostní požadavky dost slabé. V tomto případě bych použil pevné uživatelské jméno/heslo pro celou aplikaci a případně klientský certifikát X.509, pokud je Android podporuje.
Pamatujte, že bez ohledu na to, jak věci zabezpečíte, všechny přihlašovací údaje buď zná uživatel, nebo je lze z .apk triviálně získat, takže stále musíte předpokládat, že kdokoli může přistupovat k vašim metodám webových služeb, nejen k vaší aplikaci. Napište je podle toho.
Ne stačí odeslat SQL z vaší aplikace přes volání webové služby na server a vrátit výsledky jako JSON. To je děsivě nejisté, stejně jako ošklivé a neohrabané. Napište metodu webové služby pro každý jednotlivý úkol, který chcete, aby aplikace mohla provádět, a ponechejte SQL na serveru. Nezapomeňte používat parametrizované dotazy a dávejte pozor na další rizika vkládání SQL. Tyto metody webových služeb mohou používat jeden nebo více dotazů k vytvoření jediné odpovědi – můžete například shromáždit záznam „Zákazník“ a všechny související záznamy „Adresa“ a „Kontakt“ a poté vrátit výsledek v pěkném objektu JSON zařízení Android. může spotřebovat, což ušetří četné pomalé a nespolehlivé zpáteční cesty sítě.
Bez ohledu na to, co používáte, ujistěte se, že volání webové služby provádíte v pracovním vláknu na pozadí a neblokujete uživatelské rozhraní. Buďte připraveni na časové limity a chyby a na nutnost opakování. Otestujte svou aplikaci simulací občasné ztráty připojení, vysoké latence a vysoké míry ztráty paketů a ujistěte se, že zůstane použitelná.