Utilizarea Web Services Pentru Aplicatii Mobile

Informatica

Utilizarea Web Services Pentru Aplicatii Mobile

Byadmin ianuarie 1, 2024

Utilizarea web services

pentru aplicații mobile

Cuprins

Introducere

1. Capitolul I Servicii WEB

1.1. Servicii de tip SOAP

1.1.1. Stiva protocoalelor WS SOAP

1.1.2. Specificații WS*

1.1.3. Clasificări web services SOAP

1.1.4. Creare unui WS in java folosind JAX-WS

1.1.5. Apelarea unui WS in java folosind HttpURLConnection

1.1.6. Apelarea unui WS din java

1.2. Servicii de tip REST

1.2.1. Principiile arhitecturii REST

1.2.2. Crearea unui serviciu web de tip REST în java

1.2.3. Crearea unui serviciu de tip REST in PHP

1.3. Comparație intre serviciile web SOAP-REST

1.4. Implementări WS cunoscute

2. Capitolul II Aplicații mobile

3. Capitolul III Apelarea serviciilor web din aplicații mobile

3.1. Apelul unui web serviciu din Android

3.2. Apelul unui web serviciu din IOS

3.3. Apelul unui web serviciu din HTML5

4. Capitolul IV AdmDoc – Sistem integrat pentru Managementul Proiectelor

4.1. Arhitectura aplicației

4.2. Tehnologii folosite

4.3. Instalarea și configurarea aplicației

4.4. Funcționalitățile aplicației web

4.4.1. Tehnologii folosite în aplicația web

4.4.2. Meniu aplicație

4.4.3. Modul clienți

4.4.4. Modul proiecte

4.4.5. Modul documentații proiecte

4.4.6. Modulul status primărie

4.4.7. Modulul Registru casa

4.4.8. Configurare

4.4.9. Administrare utilizatori și roluri

4.4.10. Securitate

4.4.11. Servicii web expuse de aplicația web

4.5. Aplicația mobilă

4.5.1. Descrierea modului de funcționare

4.5.2. Securitate aplicației mobile

4.5.3. Funcționalități

4.5.4. Modul Proiecte

4.5.5. Modul status primărie

4.5.6. Modul registru de casă

Concluzii

Acronime

Bibliografie

Introducere

Scopul acestei lucrări este de a prezenta diverse moduri de interacțiune între aplicațiile mobile si serviciile web (web services). În lucrare se va face o prezentarea a tipurilor de servicii web cele mai folosite azi și vor fi prezentate tehnologiile care sunt utilizate în aplicația practică. De asemenea se vor prezenta cele mai folosite metode de dezvoltare pentru aplicațiile mobile și pentru fiecare metodă care sunt avantajele și dezavantajele sale.

Serviciile web sunt tot mai folosite in mediul distribuit. Aplicațiile comunică între ele cel mai adesea cu ajutorul serviciilor web. Sunt tehnologii relativ moderne, care s-au dezvoltat mai ales in ultimii ani, sunt foarte răspândite și au o largă implementare in diferite limbaje de programare sau platforme de operare.

În ultimul timp, odată cu creșterea numărului de telefoane inteligente (smartphone), a apărut o cerere tot mai mare pentru dezvoltarea de aplicații pentru telefoanele mobile. La multe din aplicațiile web existente, se dorește să existe si o aplicație specializată pentru device-uri mobile care să aibă o parte din funcționalitățile aplicației web. De multe ori cele două aplicații afișează același conținut, dar prezentat altfel. Fiind vorba de aceleași date, informația poate fi expusă prin servicii web, care pot fi apelate atât de către aplicația web, cât și de către aplicația de mobil.

Aplicațiile pentru dispozitivele mobile pot fi scrise în limbajele native ale sistemelor de operare, in java pentru Android sau Objective C pentru IOS, dar există și posibilitatea de a scrie aplicații pentru sisteme mobile utilizând tehnologii web ca HTML, CSS si javascript și care să fie portate pe diferite platforme cu ajutorul unor frameworkuri de dezvoltare. Astfel de framework-uri, având la baza HTML5 și javascript, permit o dezvoltare mult mai rapidă a aplicațiilor pentru platformele mobile. Pentru aceleași surse ale aplicației se pot genera pachete care se pot executa pe diferite platforme mobile. Practic dezvoltatorul nu mai trebuie să cunoască api-urile specifice fiecărei platforme în parte.

La partea practică am dezvoltat o aplicație web folosită de o firma de proiectare în construcții din Cluj. Aplicația tine evidența proiectelor in desfășurare, a clienților, cheltuielilor și încasărilor pentru fiecare proiect in parte, a registrului de casa. De asemenea, permite listarea documentațiilor și cererilor pentru diferite autorizații necesare in faza de proiectare. Permite interogarea automată a site-ul primăriei pentru a afla stadiul in care ce găsește o anumită cerere. Există și o versiune mobilă pentru aplicație care permite sa se efectueze diverse operații de pe un smartphone (Android, IOS, Windows mobile, etc). Versiunea mobilă este construită folosind frameworkul PhoneGap și are la bază JQuery Mobile. Aplicația mobilă apelează servicii web expuse de către aplicația principală. Aplicația principală este scrisa folosind frameworkul PHP CodeIgniter, iar baza de date este in MySQL.

În capitolul 1 „Servicii Web” sunt prezentate noțiuni generale despre serviciile web și sunt detaliate cele mai folosite web servicii actuale, cele de tip SOAP si cele de tip REST. În acest capitol se face și o comparație între cele doua tehnologii, cu avantajele și dezavantajele fiecăreia. Se prezintă modul de creare a unui webservice REST sau SOAP folosind diverse tehnologii și se arată modul cum poate fi apelat.

Capitolul 2 „Aplicații mobile” prezintă diferite tehnologii de a realizare a unei aplicații mobile și arată avantajele sau dezavantajele fiecăreia.

Capitolul 3 “Apelarea serviciilor web din aplicații mobile “ arată diverse moduri de a apela un web service dintr-o aplicație mobilă. Se exemplifică modul de apel nativ din Android și IOS și apelarea din HTML5.

Capitolul 4 „AdmDoc – Sistem integrat pentru Managementul Proiectelor” este prezentată aplicația practică. Sunt prezentate tehnologiile folosite de către aplicația mobilă și de către aplicația web. Capitolul prezintă și cele mai importante funcționalități ale aplicației dezvoltate.

Capitolul I Servicii WEB

Serviciile web sunt tot mai des utilizate azi pentru a comunica intre diverse aplicații. Ele pot sa fie accesate ușor de către clienți în internet fiind și un mod de comunicare tot mai des folosit intre aplicații diferite. Același serviciu web poate sa fie accesat de clienți diferiți, dezvoltați in limbaje de programare si tehnologii diferite.

Serviciile web apar prima dată spre sfârșitul anilor 1990, când Microsoft si alte companii au folosit protocolul Remote Procedure Call (RPC) bazat pe XML care să poate lucra peste HTTP. După anii 2000 serviciile web devin din ce în ce mai folosit ca mod de comunicare între aplicații.

Serviciul web este un sistem software proiectat pentru a suporta interacțiunea interoperabilă mașină la mașină peste o rețea. Ele sunt adesea doar interfețe de programare a aplicațiilor (API) expuse in rețea care pot fi apelate de clienți și execută un set limitat de operații. Un web serviciu permite acces la funcționalitățile aplicației folosind tehnologii standard internet. Asta înseamnă că dacă aplicația poate fi accesată din internet folosind o combinație de protocoale ca HTTP, XML, SMTP atunci este un web serviciu (Snell et all :2001).

Diferența cea mai importantă dintre un web serviciu si o aplicație web clasică este in formatul documentelor primite de client si a modului cum sunt ele folosite: în aplicația web clientul recepționează format HTML care este transformat de browser în pagini afișate, pe când clientul unui serviciu web primește un format XML sau JSON care este folosit de aplicația client. Serviciile web utilizează protocoale standard web cum ar fi HTTP, XML, SOAP, WSDL si UDDI.

In funcție de tehnologiile folosite cele mai utilizate servicii web sunt:

Servicii de tip SOAP in care comunicația este pe bază de mesaje SOAP, mesajele se transmit peste HTTP sau alte protocoale.

Servicii de tip REST (RESTful Web Service) în care cererile clienților sunt comenzi HTTP (GET, PUT, POST, DELETE) iar răspunsurile sunt in format XML sau JSON

Avantajele utilizării web serviciilor

Ușurința de comunicare intre aplicații

Ușurința de a refolosi web serviciile existente

Ușurința de a distribui informația la mai mulți consumatori

Folosesc standarde web

Pot sa fie implementate pe platforme diferite folosind diverse limbaje de programare

clienții pot sa fie la rândul lor implementați in diferite tehnologii și limbaje de programare

pot sa fie apelați cu ușurința peste proxy sau firewall-uri

Servicii de tip SOAP

Sunt serviciile web cele mai folosite, în care cererile si răspunsurile au forma unor mesaje SOAP transmise peste HTTP. La aceste servicii web furnizorul expune o descriere a interfeței API sub forma unui document WSDL, care este tot un document in format XML și poate fi prelucrat de către client. Un client poate să afle operațiile oferite de către serviciul web din descriere WSDL-ului.

Stiva protocoalelor WS SOAP

Avem 4 nivele de baza:

Transport:

Nivelul este responsabil de transportul mesajului intre server si clietn

Se pot folosi protocoalele: HTTP, HTTPS, JMS, SMTP, si FTP sau altele.

Mesagerie :

Responsabil pentru codarea mesajelor intr-un format XML astfel încât mesajele sa fie înțelese in ambele părți, de către client și de către server

Unul dintre cele mai folosite moduri de împachetare este SOAP, care este bazat pe XML

Descriere :

Este responsabil cu descrierea interfeței publice a web serviciului. Arată în ce mod clientul poate accesa și folosi serviciului web. Descrierea este realizată prin WSDL (Web Service Description Language)

Descoperire : furnizează mecanismul prin care un serviciu web se poate înregistra pentru a fi găsit mai ușor de către clienți. Unul dintre cele mai cunoscute mecanisme de descoperire disponibil este proiectul UDDI (Universal Description, Discovery and Integration). Mai este o inițiativă făcută de IBM și Microsoft care au propus o alternativă la UDDI numită Web Service Inspection Language (WS-Inspection)

HTTP (Hypertext Transfer Protocol) este standardul de comunicație peste Internet fiind standardizat de Word Wide Web Consortium (W3C).

XML (eXtensible Markup Language) este un bine cunoscut standard pentru stocare, transport și schimb de date.

SOAP este un protocol simplu, utilizat pentru transferul si codificarea informație intr-un mediu distribuit. SOAP inițial a fost perceput ca Simple Object Access Protocol, iar mai târziu și ca Service Oriented Architecture Protocol, dar acum este doar SOAP. El va fi descris mai jos. WSDL (Web Services Description Language) – este limbat bazat pe XML pentru a descrie serviciul web.

Protocolul SOAP

El înlocuiește protocoale mai vechi de comunicare între obiecte aflate pe mașini diferite ca IIOP (RMI), CORBA, DCOM, JAX-RPC, etc. Intre serviciul web si client se schimba mesaje SOAP. SOAP este un document XML cu o anumită structură. Deoarece XML nu ține de o aplicație particulară, sistem de operare sau limbaj de programare el poate fi utilizat în diferite platforme. Mesajele SOAP au o parte care nu poate sa lipsească (SOAP part) si o parte opțională (Attachments). Partea fixă conține o anvelopă (SOAP Envelope) care are o parte opțională de antet (SOAP Header) si o parte obligatorie de corp de mesaj.

Exemplu apel (request) WS:

<soapenv:Envelope

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:tes="http://testws.ro/">

<soapenv:Header/>

<soapenv:Body>

<tes:calc>

</tes:calc>

</soapenv:Body>

</soapenv:Envelope>

Exemplu răspuns WS:

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">

<S:Body>

<ns2:calcResponse xmlns:ns2="http://testws.ro/">

<return>rezultat : 11 !</return>

</ns2:calcResponse>

</S:Body>

</S:Envelope>

WSDL (Web Services Description Language)

WSDL-ul (Limbajul de Descriere a Serviciilor Web) este bazat pe XML si descrie serviciile web. Pentru a evita conflictele intre numele atribuite diverselor elemente din WSDL se recomandă să se utilizeze denumiri calificate. Structura unui WSDL este următoarea:

<types>

</types>

</message>

<PortTste limbat bazat pe XML pentru a descrie serviciul web.

Protocolul SOAP

El înlocuiește protocoale mai vechi de comunicare între obiecte aflate pe mașini diferite ca IIOP (RMI), CORBA, DCOM, JAX-RPC, etc. Intre serviciul web si client se schimba mesaje SOAP. SOAP este un document XML cu o anumită structură. Deoarece XML nu ține de o aplicație particulară, sistem de operare sau limbaj de programare el poate fi utilizat în diferite platforme. Mesajele SOAP au o parte care nu poate sa lipsească (SOAP part) si o parte opțională (Attachments). Partea fixă conține o anvelopă (SOAP Envelope) care are o parte opțională de antet (SOAP Header) si o parte obligatorie de corp de mesaj.

Exemplu apel (request) WS:

<soapenv:Envelope

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:tes="http://testws.ro/">

<soapenv:Header/>

<soapenv:Body>

<tes:calc>

</tes:calc>

</soapenv:Body>

</soapenv:Envelope>

Exemplu răspuns WS:

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">

<S:Body>

<ns2:calcResponse xmlns:ns2="http://testws.ro/">

<return>rezultat : 11 !</return>

</ns2:calcResponse>

</S:Body>

</S:Envelope>

WSDL (Web Services Description Language)

WSDL-ul (Limbajul de Descriere a Serviciilor Web) este bazat pe XML si descrie serviciile web. Pentru a evita conflictele intre numele atribuite diverselor elemente din WSDL se recomandă să se utilizeze denumiri calificate. Structura unui WSDL este următoarea:

<types>

</types>

</message>

</operation>

</PortType>

</operation>

</binding>

</service>

</definitions>

Următorul exemplu este un WSDL pentru un web service care are o singură operație getInfo, primește in request un id de persoană și întoarce informații despre persoana respectivă: nume, prenume și vârstă.

Specificații WS*

WS* adaugă specificații noi pentru serviciile Web cum ar fi:

Clasificări web services SOAP

Literal înseamnă ca mesajul body-ul SOAP urmărește o schema XML care este incluse in WSDL document. Clientul dacă are acces la WSDL știe cum să formateze mesajul.

Encoded – body-ul SOAP nu urmează o schemă, dar urmează un format specific pe care clientul se presupune ca-l cunoaște. Nu este compatibil WS-I standard.

In funcție de stilul de legare (menționat in WSDL sub numele soap:binding styles) se împart in următoarele categorii:

Stilul RPC (Remote Procedure Call) – specifică faptul că eticheta (envelope) conține un element cu numele metodei web de invocate (element înfășurător, plic). Acest element, la rândul său, conține o intrare pentru fiecare parametru și pentru valoarea returnată a acestei metode

Stilul Document – nu există nici un element înfășurător (plic), cum este cazul stilului RPC. În schimb, părțile de mesaj apar direct sub elementul body .

Standardul WS-I Basic Profile 1.1 (Web Services Interoperability) specifică cerințele impuse implementărilor de servicii web pentru a asigura interoperabilitatea lor.

Cele mai folosite versiuni de SOAP sunt Versiunea 1.1 si versiunea 1.2. Versiunea 1.2 reprezintă efortul consorțiului W3C de a standardiza protocolul SOAP, dar deja multe versiuni SOAP 1.1 fuseseră deja implementate. Implementări de web services mai cunoscute care folosesc specificațiile versiunii 1.2 sunt SOAP:Lite pentru Perl, Apache SOAP 2.2, Apache Axis. Dacă un webservice versiune 1,1 primește un mesaj versiune 1.2 atunci el va respinge mesajul, pe când un webservice versiune 1.2, dacă primește un mesaj versiune 1.1 el poate să accepte acel mesaj. Versiunea mesajului SOAP se poate determina din namespace definit pentru SOAP envelope astfel:

În funcție de modul cum sunt definite in WSDL avem următoarele stiluri de mesaje SOAP:

Creare unui WS in java folosind JAX-WS

Pentru crearea unui serviciu Web se poate porni de la un WSDL existent (top-down) sau de la un program sursa Java (bottom-up) din care se creează WSDL.

Pentru a dezvolta un serviciul web pornind de la sursa Java se procedează astfel:

Se creează un proiect de tip “Web Application”

Se creează o clasă nouă (de exemplu HelloWS1) care conține:

package ro.testws;

import javax.jws.WebMethod;

import javax.jws.WebParam;

import javax.jws.WebService;

@WebService(serviceName = "Hello")

public class Hello {

@WebMethod(operationName = "salut")

public String hello(@WebParam(name = "nume") String nume) {

return "Hello " + nume + " !";

}

@WebMethod(operationName = "calc")

public String calc(@WebParam(name = "a") int a,@WebParam(name = "b") int b) {

return "rezultat : " + String.valueOf(a+b) + " !";

}

În sursa programului se folosesc mai multe adnotări (annotation) astfel:

@WebService – specifică că este vorba de un web serviciu

@WebMethod – specifică numele operației

@ WebParam – specifică parametri pentru web serviciu

Deși pare complicat să creezi un WS pornind de la WSDL, există editoare care permit să se definească în mod vizual WSDL-ul. Un astfel de editor exista in IDE-ul Eclipse, destul de ușor de folosit.

Apelarea unui WS in java folosind HttpURLConnection

Metoda 1.

Se construiește mesajul XML ( se poate folosi pentru asta utilitarul SOAPUI)

Se face apel către serviciu web folosind clasa java HttpURLConnection

URL url;

try {

url = new URL("http://localhost:8080/HelloWS1/Hello");

HttpURLConnection httpConn = (HttpURLConnection) url.openConnection();

httpConn.setRequestMethod("POST");

httpConn.setRequestProperty("Content-type", "text/xml; charset=utf-8");

httpConn.setRequestProperty("SOAPAction", "");

httpConn.setDoInput(true);

httpConn.setDoOutput(true);

String reqXML = msg;

/* de forma "<soapenv:Envelope ….. </soapenv:Envelope>" */

OutputStream outStr = httpConn.getOutputStream();

outStr.write(reqXML.getBytes());

outStr.close();

if (httpConn.getResponseCode() == HttpURLConnection.HTTP_OK) {

InputStreamReader isr = new InputStreamReader(

httpConn.getInputStream());

BufferedReader in = new BufferedReader(isr);

String inputLine;

while ((inputLine = in.readLine()) != null) {

System.out.println(inputLine);

}

in.close();

}

} catch (Exception ex) {

Logger.getLogger(TestWS.class.getName()).log(Level.SEVERE, null, ex);

}

Apelarea unui WS din java

Există mai multe moduri de a apela un web serviciu folosind funcționalități din Eclipse sau NetBeans. În cele ce urmează mă voi referi la un mod de a apela un client din Eclipse pe care l-am folosit de mai multe ori pentru a apela un webservice. Se creează un proiect de tip „Dynamic Web Project”, după care se va crea folosind wizzard-ul un „Web Service Client” . În pașii de creare a clientului web se va selecta :

La Service Definition – se va pune adresa wsdl-ului sau se va selecta wsdl-ul

Client Type – se lasă implicit pe „Java Proxy”

Wizzard-ul va crea automat mai multe clase java folosite pentru apelul webserviciului. Pentru apelul webservice se folosește clasa generată <NumeWS>Proxy care conține toate metodele expuse de webservice. Acest mod de apel al unui web serviciu implică regenerarea clientului ori de cate ori se modifică serviciul web.

Există și posibilitatea de a apela dinamic din java un web serviciu, pentru asta trebuie să trebuie sa știm endpoint-ul, serviceName și portName, informții care sunt găsite în WSD:

String endpointUrl = "http://localhost:8080/helloserv/CalculatorService";

QName serviceName = new QName("http://ws.testws.ro/", "CalculatorService");

QName portName = new QName("http://ws.testws.ro/", "CalculatorPort");

Service service = Service.create(serviceName);

service.addPort(portName, SOAPBinding.SOAP11HTTP_BINDING, endpointUrl);

Dispatch<SOAPMessage> dispatch = service.createDispatch(portName, SOAPMessage.class, Service.Mode.MESSAGE);

String str=getMsg();

InputStream istr = new ByteArrayInputStream(str.getBytes());

SOAPMessage request = MessageFactory.newInstance().createMessage(null, istr);

dispMsg(request);

SOAPMessage response = dispatch.invoke(request);

dispMsg(response);

Servicii de tip REST

REpresentational State Transfer (REST) este un model de arhitectură de aplicație distribuită în care se specifică modul cum o resursă – entitate care conține informația specifică – este definită și cum poate fi adresată. Termenul de Servicii REST este folosit prima data de către Roy Fielding în anul 2000, în lucrarea sa de doctorat “Architectural Styles and the Design of Network- based Software Architectures". Identificarea unei resurse se face printr-un URI (Universal Resource Identifier). Transferul resursei către un client sau prelucrarea resursei se face utilizând o interfață care conține operațiile http: GET, POST, PUT, DELETE. Deși REST nu este un standard, el se folosește de standarde:

HTTP ( Hypertext Transfer Protocol),

URI ( Uniform Resource Identifier)

XML/HTML/GIF/JPEG.

Resursele sunt fără stare iar modelul de aplicație este cel de client-server. Principalul exemplu de sistem RESTful este World Wide Web (WWW) cu protocolul Hyper Text Transfer Protocol (HTTP). Serviciile Web bazate pe REST se bazează pe accesul la resurse – definite prin identificatori si nu pe apelarea unor metode ca in modelul Remote Procedure Call (RPC). Serviciile de tip REST (RESTful Web Service) sunt serviciile web in care cererile de la client se exprima prin comenzi HTTP (GET, PUT, POST, DELETE) iar răspunsurile sunt primite ca si documente XML sau JSON. Exemple de web servicii de tip REST notabile sunt : Amazon S3 (Simple Storage Service) pentru memorarea și regăsirea obiectelor, rețeaua Twitter si alte site-uri de blog in care se descarcă fișiere în format RSS sau Atom cu liste de legături către alte resurse.

Principiile arhitecturii REST

Resursa este o entitate care se poate stoca intr-un computer si se poate reprezenta printr-un sir de biți. Exemple de resurse: un document pdf, un fișier de muzică mp3, un rând dintr-o tabelă. Fiecare resursă are atașat un identificator global numit URI. Pentru a manipula resursele se comunică printr-o interfață standardizată ( de exemplu HTTP).

URI (Uniform Resource Identifier). Orice resursa trebuie sa aibă cel puțin un URI. URI-ul este numele si adresa resursei. URI-urile trebuie sa fie descriptive si sa existe o corespondență intuitiva intre URI si resursă.

Adresabilitatea. O aplicație este adresabilă daca expune informații ca și resurse. Cum resursele sunt expuse prin URI-uri rezultă ca o aplicație adresabilă are un URI pentru orice informație expusă.

Fară stare. Lipsa stării se traduce prin faptul că orice cerere HTTP este izolată, nu depinde de alte cereri anterioare. Clientul va trimite toate informațiile necesare pentru fiecare cerere, iar interacțiunea dinte client și servere durează doar atât timp cat durează cererea.

Reprezentari. O reprezentare este formată din date despre stare curentă a unei resurse. Pentru orice resursa putem avea mai multe reprezentări ale acesteia, iar clientul poate să aleagă o anumită reprezentare. De exemplu un comunicat de presă poate sa aibă versiuni in limbi diferite. Conținutul poate sa fie accesat cu URI-uri diferite sau sa avem un singur URI iar conținutul sa fie negociat.

Interfața uniforma. HTTP ofera patru metode de bază pentru cele mai comune operații.

GET – returnează reprezentarea unei resurse

PUT – pentru a pune documente pe server

POST pentru a trimite date de intrare către server

DELETE – pentru ștergerea unei resurse.

Alte operații folosite de către protocolul HTTP sunt :

HEAD- întoarce antetul unei resurse

TRACE – pentru diagnosticare

OPTIONS – pentru identificarea unor opțiuni ale serverului

Crearea unui serviciu web de tip REST în java

Există mai multe moduri de creare automată a unui web serviciu in java folosind Eclipse sau NetBeans. De exemplu în NetBeans se poate crea automat pentru tabele din baza de date servicii REST. Pentru asta trebui doar sa selectezi conexiunea la baza de date, se selectează tabelele și restul este făcut automat de către IDE. Dacă se vrea să se genereze un web service dintr-o clasă java folosind JAX-RS, in NetBeans se generează mai întâi un proiect de tip „Web Application”, după care în cadrul proiectului, se selectează creare de webservice de tip „Restful Web Services from Patterns” , după care se selectează “Simple Root Resource”

Clasa java generată poate conține următoarea secvență:

package testWS;

import javax.ws.rs.core.Context;

import javax.ws.rs.core.UriInfo;

import javax.ws.rs.PathParam;

import javax.ws.rs.Consumes;

import javax.ws.rs.PUT;

import javax.ws.rs.Path;

import javax.ws.rs.GET;

import javax.ws.rs.POST;

import javax.ws.rs.Produces;

import javax.ws.rs.core.Response;

@Path("testws")

public class TestWS {

@Context

private UriInfo context;

public TestWS() {

}

// http://localhost:8080/testwsrest/webresources/testws/get

@GET

@Path("/get")

@Produces("application/json")

public TypeDate1 getJson() {

TypeDate1 td=new TypeDate1();

td.setNume("NUME1");

td.setValoare("VALOARE1");

return td;

}

//http://localhost:8080/testwsrest/webresources/testws/get/test

@GET

@Path("/get/{idvalue}")

@Produces("application/json")

public TypeDate1 getJsonParam(@PathParam("idvalue") String idvalue) {

TypeDate1 td=new TypeDate1();

td.setNume("nume_"+idvalue);

td.setValoare("val_"+idvalue);

return td;

}

@POST

@Path("/post")

@Produces("application/json")

public Response getMSg(TypeDate1 td) {

String result = "Data post: "+td;

System.out.println( td.getNume());

System.out.println( td.getValoare());

return Response.status(201).entity(result).build();

}

@PUT

@Consumes("application/json")

public void putJson(String content) {

}

La un apel de genul http://localhost:8080/testwsrest/webresources/testws/get/1 webservices va intoarce următorul răspuns de tip JSON: {"nume":"nume_1","valoare":"val_1"}.

Crearea unui serviciu de tip REST in PHP

Webservice de tip REST răspunde în format JSON sau XML. Un răspuns în format JSON arată astfel:

{ "ID": "1", "Name": "Popescu","Email": "[anonimizat]"}

Pe când răspunsul in format xml arată așa:

<?xml version="1.0" encoding="UTF-8"?>

<nume>Ion Popescu</nume>

<email>[anonimizat]</email>

</response>

Un exemplu simplu care arată cum ar trebui să raspundă în format JSON un web service in PHP este urmatorul:

<?php

header('Content-type: application/json');

$response["nume"]="Popescu";

$response["email"]="[anonimizat]";

echo json_encode($response);

?>

Următorul exemplu arată un web service care răspunde în format XML.

<?php

header('Content-Type: application/xml; charset=utf-8');

$response["nume"]="Popescu";

$response["email"]="[anonimizat]";

$xml_response = '<?xml version="1.0" encoding="UTF-8"?>'."\n".

'<response>'."\n".

"\t".'<nume>'.$response['nume'].'</nume>'."\n".

"\t".'<email>'.$response['email'].'</email>'."\n".

'</response>';

echo $xml_response;

?>

Comparație intre serviciile web SOAP-REST

Serviciile de tip SOAP oferă mai multă flexibilitate, o mai buna calitate a serviciilor si interoperabilitate decât serviciile REST si sunt recomandate pentru un API mai mare oferit clienților. Serviciile de tip SOAP pot fi combinate pentru a realiza operații complexe, ceea ce a condus la o arhitectura orientată pe servicii (SOA=Service Oriented Architecture). Webserviciile SOAP sunt supuse regulilor W3C ceea ce duce la o standardizare pe când la cele de tip REST nu avem un set elaborat de standarde. De asemenea serviciile web SOAP acceptă mai multe tipuri de transport a datelor cum ar fi JMS, SMTP si altele.

Serviciile web de tip REST sunt mai ușor de construit ca de altfel și clienții pentru acestea. REST permite mai multe formate pentru mesaj pe când cele de tip SOAP doar format XML. WS-urile de tip REST pot sa folosească tehnologia cache. Unii autori recomandă să se folosească SOAP doar atunci când sunt motive speciale să se folosească această tehnologie, altfel să se folosească web services de tip REST .

Există unele extensii ale serviciilor web care sunt asigurate doar de serviciile web de tip SOAP. Astfel avem următoarele standarde:

-WS-Security, care în mediul enterprise permite verificarea identitații intermediar, nu doar punct-la-punct ca în cazul protocolului SSL. Protocolul SSL poate fi folosit și de către web serviciile REST. De asemenea este un standard pentru integritatea datelor și protecția datelor

– WS-AtomicTransaction permite tranzacții atomice pentru serviciile web de tip SOAP, astfel putem să avem tranzacții în mai mulți pași separați.

– WS-ReliableMessaging, standard care permite pentru serviciile SOAP să permită automat retransmiterea mesajului în caz de eroare de comunicare. În cazul serviciilor REST se aștepta să se reîncerce trimiterea mesajului.

Implementări WS cunoscute

Microsoft

A dezvoltat standardul SOAP

Se pot face dezvoltări in limbaje de programare precum C#, VB.NET si altele

Tehnologiile se bazează pe serverul IIS, care nu prea este folosit in medii enterprise

Java

Sun Microsystems (deținută acum de Oracle), creatorul limbajului Java, a lansat tehnologiile folosite de serviciile web sub nume de WS*

Alte implementari BEA WebLogic (deținută acum tot de Oracle), IBM – WebSphere , etc

Implementări JAVA cunoscute: CXF (fost XFire) , Apache, Metro (Sun), Axis 1 și 2 (Apache), Jersey (Sun)

SoapUI este cel mai cunoscut instrument pentru simularea unui client de servicii Web (prin afișarea cererilor client si răspunsurilor primite), pentru testarea si dezvoltarea de servicii SOAP si REST. Este un tool care se poate folosi in regim de Open Source si cunoaște mai multe protocoale ca de exemplu SOAP, REST, HTTP, JMS. Daca se introduce WSDL-ul serviciului WEB utilitarul generează automat operațiile și formatul mesajelor de request.

Capitolul II Aplicații mobile

Peste două treimi din numărul telefoanelor vândute in ultimul an sunt telefoane inteligente (smartphone), tot mai mulți utilizatori au acces la internet de pe telefoane, astfel ca numărul de aplicații pentru telefoanele mobile este intr-o continuă creștere. Cele mai vândute sisteme de operare pentru telefoanele mobile inteligente sunt Android si IOS care aveau in 2015 T1 împreună in jur de 96% (78% Android și 18.3% IOS) conform site-ului de specialitate www.idc.com ( http://www.idc.com/prodserv/smartphone-os-market-share.jsp) .

Android este o platformă software și un sistem de operare pentru dispozitive mobile bazat pe nucleul Linux. El a fost dezvoltat inițial de compania Google, iar mai târziu de un consorțiu comercial Open Handset Alliance.

IOS este tot un sistem de operare bazat pe nucleul Unix pentru diverse dispozitive, dezvoltat de compania Apple, care conține mai multe elemente din Mac OS X.

Pentru dezvoltarea aplicațiilor pentru Android se folosește mult mediul de dezvoltare Eclipse cu plugin-ul ADT și mai nou Android Studio (folosește ca și IDE IntelliJ Idee). Pentru dezvoltarea aplicații mobile pentru IOS se folosește platforma XCode, care rulează pe sistemul de operare MacOS.

Exista trei moduri de a dezvolta aplicații mobile.

Primul este modul nativ care însemnă ca aplicația este dezvoltată să ruleze pe un sistem de operare specific. Aplicația se descarcă și se instalează pe device-ul mobil. Astfel avem platformele native IOS SDK (limbaj Objective C), Android SDK (limbaj Java) si Windows Phone SDK (limbaj .NET). Aplicațiile sunt mai dificil de dezvoltat dar sunt cele mai rapide în utilizare. Dezvoltatorul are acces la toate facilitățile dispozitivului.

Există posibilitatea de a dezvolta aplicația în modul cross-platform ceea ce înseamnă că folosind un framework, aplicația poate sa fie instalată pe mai multe platforme. Cele mai cunoscute platforme de dezvoltare sunt Titanium Appcelerator, Phonegap, Sencha, Mobile Angular și altele. Dezvoltarea se face în javascript și HTML iar frameworkul transformă aplicația în pachete care pot sa fie rulate în device-urile mobile. Acest mod de dezvoltare prezintă avantajul că dezvoltarea se face mai ușor, avem o singură sursă de cod pentru aplicație, care se va putea instala pe diferite platforme mobile. Dezvoltatorul are acces la o mare parte din facilitățile tehnice ale dispozitivului mobil, dar înainte de a începe o astfel de dezvoltare, trebuie avut în vedere dacă cerințele tehnice ale aplicației pot sa fie asigurate. Rulează mai încet decât o aplicație scrisă în mod nativ, dar dacă se adaptează aplicația cu caracteristicile specifice fiecărei platforme se poate îmbunătății modul de răspuns. Când apar noi funcționalități în platformele mobile durează ceva timp până vor putea fi folosite de către aceste frameworkuri de dezvoltare. Ca și cele native se instalează în dispozitivele mobile.

Mai există al treilea mod numit Mobile Web, in care aplicația este instalată pe un server web și este accesată de device-ul mobil din browser. Ele sunt independente de platformă, sunt ușor de dezvoltat dar prezintă dezavantajul ca nu au acces la resursele hardware sau software ale dispozitivelor mobile și că depind de o conexiune la internet. HTML5 ultima versiune pentru HTML, permite aplicațiilor să arate asemănător cu cele scrise în mod nativ și pot sa ruleze și în mod offline. Ele rulează totuși mai încet decât aplicațiile native.

Capitolul III Apelarea serviciilor web din aplicații mobile

În continuare voi prezenta modul de apel pentru web services din diverse platforme folosind diferite limbaje de programare. La apelul unui serviciu web trebuie sa știm endpoint-ul la care se apelează și operația serviciului în cazul WS-urilor de tip SOAP.

Apelul unui web serviciu din Android

Pentru a apela un webservice SOAP dintr-o aplicație nativă java, se poate folosi clasa HttpURLConnection sau se poate folosi pachetul ksoap2 (http://kobjects.org/ksoap2/index.html).

Pentru un apel de serviciu web de tip REST se poate folosi clasa com.loopj.android.http.AsyncHttpClient ( http://loopj.com/android-async-http/). In fișierul de configurare AndroidManifest.xml ar trebui să avem permisiunea de acces la internet.

<uses-permission android:name="android.permission.INTERNET" />

Apelul unui webservice de tip REST se poate face astfel:

public void invokeWS(){

// apel webservice folosind AsyncHttpClient

RequestParams params=new RequestParams();

AsyncHttpClient client = new AsyncHttpClient();

client.get("http://10.148.1.16/admdoc/wsexecute/testws",params ,new AsyncHttpResponseHandler() {

// cod succes apel Http response code '200'

@Override

public void onSuccess(String response) {

try {

// JSON Object

JSONObject obj = new JSONObject(response);

System.out.println(obj.getString("nume"));

System.out.println(obj.getString("varsta"));

} catch (JSONException e) {

e.printStackTrace();

}

// raspuns eronat

@Override

public void onFailure(int statusCode, Throwable error, String content) {

System.err.println(statusCode+" "+error);

}

});

}

Apelul unui web serviciu din IOS

În continuare va fi prezentat un exemplu de apel de webservice de tip SOAP din IOS, folosind limbajul Objective C. Mai multe informații despre modul cum se poate apela un webservice din IOS se poate găsi în documentația Apple la adresa https://developer.apple.com/library/mac/documentation/Networking/Conceptual/UsingWebservices/Tasks/Tasks.html.

// initializarea SOAP request

NSURL *url = [NSURL URLWithString:@"http://localhost:8888/"];

NSString *method = @"execute";

NSString *namespace = @"http://www.myws.ro/";

// parametri SOAP

NSDictionary *params = [NSDictionary dictionaryWithObject:@"info 1" forKey:@"param"];

NSArray *paramOrder = [NSArray arrayWithObject:@"param"];

// http header pentru SOAP request

NSDictionary *reqHeaders = [NSDictionary dictionaryWithObject:@"" forKey:@"SOAPAction"];

// construieste SOAP request folosind funcția definită mai jos createSOAPRequest

WSMethodInvocationRef soapReq = createSOAPRequest(url, method, namespace, params, paramOrder, reqHeaders);

// apel SOAP request

NSDictionary *result = (NSDictionary *)WSMethodInvocationInvoke(soapReq);

// codul de raspuns HTTP al apelului se poate obține astfel

CFHTTPMessageRef res = (CFHTTPMessageRef)[result objectForKey:(id)kWSHTTPResponseMessage];

// functia responsabilă cu trimiterea SOAP request, întoarce obiect WSMethodInvocationRef

WSMethodInvocationRef createSOAPRequest(NSURL *url,

NSString *method,

NSString *namespace,

NSDictionary *params,

NSArray *paramOrder,

NSDictionary *reqHeaders)

{

WSMethodInvocationRef soapReq = WSMethodInvocationCreate((CFURLRef)url,

(CFStringRef)method,

kWSSOAP2001Protocol);

// setează parametri SOAP

WSMethodInvocationSetParameters(soapReq, (CFDictionaryRef)params, (CFArrayRef)paramOrder);

// setează namespace

WSMethodInvocationSetProperty(soapReq, kWSSOAPMethodNamespaceURI, (CFStringRef)namespace);

// setează HTTP headers (cu SOAPAction header)

WSMethodInvocationSetProperty(soapReq, kWSHTTPExtraHeaders, (CFDictionaryRef)reqHeaders);

// setează parametru follow redirects.

WSMethodInvocationSetProperty(soapReq, kWSHTTPFollowsRedirects, kCFBooleanTrue);

return soapReq;

}

Apelul unui web serviciu din HTML5

În HTML5 se poate apela un serviciu web folosind javascript și apeluri AJAX. Apelul se poate face folosind jQuery și un astfel de model este folosit și la aplicația dezvoltată pentru partea practică.

$.ajax (

{

url : vserver+"/proiectcateg/"+vcateg+"/"+vidproiect,

cache: false,

type: "GET",

data : {},

contentType: "application/json; charset=utf-8",

crossDomain: true,

error: function(XMLHttpRequest, textStatus, errorThrown){

alert("Err code:"+XMLHttpRequest.status+"; Obj:"+XMLHttpRequest.statusText+"; Ajax Err:"+textStatus + "; Ajax Msg:" + errorThrown);

},

success: function(data, textStatus){

{

$.each(data, function (i, item) {

var sopt = item.nume ;

console.log(item.nume);

console.log(item.varsta);

});

}

});

Pentru ca apelul să funcționeze trebuie ca serverul pe care este instalat web services să permită apeluri javascript CROSS-DOMAIN. Mai multe informații despre cum această problemă se găsesc la subcapitolul 4.4.1.

Capitolul IV AdmDoc – Sistem integrat pentru Managementul Proiectelor

Arhitectura aplicației

Aplicația principală expune prin servicii web diferite funcționalități care pot să fie apelate de către aplicația mobilă. Aplicația mobilă apelează prin apeluri ajax, folosind jQuery serviciile web expuse in serverul web. Răspunsul primit este in format JSON. Conectarea între aplicație și serverul de bază de date se face din configurarea frameworkul CodeIgniter după ce s-au setat parametrii de conectare la baza de date. Pot să fie folosite si alte tipuri de baze diferite cum ar fi Oracle, PostgreSQL și multe altele.

Tehnologii folosite

Aplicația dezvoltată conține două parți. O parte este aplicația web si o parte este aplicația mobilă. Ambele aplicații accesează aceeași bază de date. Aplicația mobilă are acces la informații din baza de date prin intermediul unor servicii web de tip REST expuse de către aplicația principală. Aplicația mobilă este construită folosind jQuery Mobile după care cu ajutorul platformei PhoneGap se generează pachetul pentru diferite sisteme de operare mobile cum ar fi Android, IOS sau Windows Mobile.

Aplicația web este construită având la baza frameworkul PHP CodeIgniter si jQuery. Pentru afișarea diferitelor informații în tabele este folosit un plugin jqGrid, care primește informația de afișat in format JSON specific si permite declansarea anumitor acțiuni la diferite evenimente.

PhoneGap este platformă open source care permite crearea de aplicații mobile folosind standardul web API pentru diverse platforme (IOS, Android, Windows Phone 8, Amazon Fire OS, BlackBerry, Firefox OS, etc). Același cod scris într-un anumit limbaj poate să fie generat pentru diferite platforme mobile. El folosește tehnologii standard web cum ar fi HTLM, javascript, CSS. Dezvoltatorii sau companiile pot sa folosească PhoneGap pentru a dezvolta aplicații mobile gratuite, open source sau comerciale sau combinații ale acestora.

AJAX (Asynchronous JavaScript and XML) este o tehnică prin care parți din paginile web se pot modifica prin apeluri asincrone javascript, fară să fie necesar să se reîncarce toată pagina. Acest lucru ajută mult la o navigarea mai rapidă, deoarece nu mai trebuie actualizate toate informațiile din pagină. Apelul de tip Ajax se poate realiza usor folosing jQuery.

JQuery Mobile (https://jquerymobile.com/) este un framework cross-platform cu HTML5 asemănător cu jQuery și este folosit pentru aplicațiile mobile. Folosește limbajul javascript la partea de scripting și are multe obiecte definite pentru aplicațiile mobile. În loc să scriem câte o aplicație pentru fiecare platformă mobilă în parte, folosind acest framework putem să avem o singură aplicație care să ruleze pe diferite platforme. De asemenea permite și dezvoltarea de site-uri web care pot sa fie citite ușor de către browserele din dispozitivele mobile.

CodeIgniter este unul dintre cele mai folosite frameworkuri PHP pentru dezvoltarea aplicațiilor web în mediul PHP. Este bazat pe modelul Model-View-Controller, astfel că partea de prezentare (View) este separată de partea de structuri de data (Model). Legătura se face prin intermediul Controllerului. Modelul reprezintă structurile de date și conține funcțiile pentru modificare (update/insert/get) in baza de date. Partea de “View” conține informația care este prezentă utilizatorului, in general pagini web, dar pot sa fie si fragmente de pagină (footer, header). Controller-ul este un intermediar intre „Model” și „View” sau către oricare alta resursă necesară pentru generarea paginilor web. Partea de Model poate sa lipsească. CodeIgniter are o mulțime de librării pentru a ușura dezvoltarea, dar permite să se adauge librării proprii care să fie folosite asemănător cu cele sistem.

jqGrid este un plugin javascript (http://www.trirand.com/jqgridwiki/doku.php), folosind tehnologia Ajax și este folosit pentru reprezentarea și manipularea datelor tabelare. Datele sunt încărcate dinamic prin apeluri Ajax și poate fi integrat cu diverse tehnologii pe partea de server cum ar fi PHP, ASP, JSP, java servlets si altele.

MySQL este o bază de date foarte cunoscută si des utilizată in mediul web. Există mai multe site-uri de hosting unde gratis sau destul de ieftin se poate avea acces la o baza de date MySQL pentru a dezvoltarea sau testarea in internet a unui site web dinamic.

Instalarea și configurarea aplicației

Aplicația web se poate instala într-un server Apache versiune 2 în care este instalat și configurat PHP (versiune mai mare sau egală cu 5.3). De asemenea trebuie sa avem instalat serverul MySQL 5.5. Se poate folosi pentru asta pachetul WAMPSERVER 2.2 care este gata configurat cu Apache 2.2, PHP 5.3.8 și MySQL 5.5.8.

In serverul Apache se activează din configurare modulele mod_rewrite și mod_headers. Se configurează in fișierul de configurare Apache httpd.conf să se permită apel cross-domain (vezi 4.2).

Se configurează framework-ul CodeIgniter pentru conectarea la baza de date. Configurarea se face in fișierul application\config\database.php și arată în felul următor:

$db['default']['hostname'] = 'localhost';

$db['default']['username'] = 'docuser';

$db['default']['password'] = 'xxxx';

$db['default']['database'] = 'admdb';

$db['default']['dbdriver'] = 'mysql';

$db['default']['dbprefix'] = '';

$db['default']['pconnect'] = TRUE;

În directorul rădăcină unde se afla aplicația se creează un fișier .htaccess pentru setarea Apache de mod_rewrite. Acest lucru va face ca din url-urile aplicației web dispară index.php, care altfel ar apărea peste tot în URL.

RewriteEngine on

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule .* index.php/$0 [PT,L]

</IfModule>

Funcționalitățile aplicației web

Tehnologii folosite în aplicația web

Pentru afișarea informațiilor în format grid se folosește un obiect jqGrid, care primește prin apel AJAX informațiile din baza de date in format JSON. Pentru a formata informațiile în format JSON se folosește funcția PHP json_encode.

Lucrul cu baze de date folosind CodeIgniter este elegant și ușor. După cum am precizat și anterior, legătura cu baza de date se face prin configurare, nu mai este necesar să se scrie cod pentru asta. În continuare voi arata cum arata in surse câteva din comezile SQL cele mai utilizate.

Exemplu select :

$query = $this->db->query('SELECT nume, email FROM useri');

foreach ($query->result_array() as $row)

{

echo $row['nume'];

echo $row['email'];

}

Exemplu insert:

$date = array(

'id_user' => $session_data["id"],

'desc' => $desc,

'tabela' => $tabela,

'id_tab' => $id_tab);

$this->db->insert('log_app', $date);

Exemplu update:

$data = array(

'nume' => $request_data['nume'],

'tip' => $request_data['tip'],

'cnp_cui' => $request_data['cnp_cui'],

'firma' => $request_data['firma'],

'localitate' => $request_data['localitate'],

);

$this->db->where('id', $request_data['id']);

return $this->db->update('clienti', $data);

Pentru popularea unui obiect jqGrid (folosit la grid) răspunsul JSON trebuie sa respecte un anumit format. Un exemplu de cum trebuie să fie acest format este următorul:

{"page":"1","total":1,"records":5,"start":0,"limit":"10",

"rows":[

{"id":"15","cell":["15","3","Curatenie"]},

{"id":"8","cell":["8","3","Gaz"]},

{"id":"7","cell":["7","3","Telefon"]},

{"id":"6","cell":["6","3","Electrica"]}

]}

Pregătirea pentru formatarea aceasta este făcută în aplicație în clasa genjson, metoda get_rows_json.

public function get_rows_json($total_rows, $request_data) {

$page = $request_data['page']; // numarul paginii

$limit = $request_data['rows']; // numarul de randuri in grid

$totalrows = isset($request_data['totalrows']) ? $request_data['totalrows'] : false;

if ($totalrows) {

$limit = $totalrows;

}

$count = count($total_rows);

$response = new stdClass();

if ($count > 0) {$total_pages = ceil($count / $limit);

} else { $total_pages = 0; }

if ($page > $total_pages) { $page = $total_pages; }

if ($limit <= 0) {$limit = 0;}

$start = $limit * $page – $limit;

if ($start <= 0) { $start = 0;}

$response->page = $page;

$response->total = $total_pages;

$response->records = $count;

$response->start = $start;

$response->limit = $limit;

$eligible_rows = array_slice($total_rows, $start, $limit);

$i = 0;

foreach ($eligible_rows as $row) {

$response->rows[$i]['id'] = $row->id;

$tmparray = array();

foreach ($row as $field) {

array_push($tmparray, $field); }

$response->rows[$i++]['cell'] = $tmparray;

}

return $response;

}

Funcția primește ca și parametri de intrare: înregistrările citite din baza de dată și parametri de request trimiși din pagina web. În parametrii de request se trimit și informații despre afișarea in jqGrid, cum ar fi numărul paginii, numărul maxim de înregistrări care vor fi recepționate. CodeIgniter folosește ca și structură modelul Model-View-Controller. De exemplu presupunem că avem un obiect jqGrid care afișează cursul BNR care ia informațiile printr-un apel ajax. Vom defini un controler class Cursbnr extends CI_Controller, care va avea o metoda getJson definită astfel:

public function getJson() {

try {

$response = $this->cursbnr_mod->getJson($_REQUEST);

header('Content-type: application/json');

echo json_encode($response);

} catch (Exception $e) {

$this->handle_controller_exception($e);

}

Clasa cursbnr_mod este o clasă de tip model care se apelează din controlerul cursbnr. Modelul se poate încărca în constructorul clasei astfel:

function __construct() {

$this->load->model('cursbnr_mod');

}

Funcția genJson din model cursbnr_mod arată astfel :

public function getJson($request_data) {

$page = $request_data['page'];

$limit = $request_data['rows'];

$totalrows = isset($request_data['totalrows']) ? $request_data['totalrows'] : false;

if ($totalrows) {

$limit = $totalrows;

}

$sidx = isset($request_data['sidx']) ? $request_data['sidx'] : false;

$sord = isset($request_data['sord']) ? $request_data['sord'] : false;

$this->db->select('id,curs,data');

$this->db->from('curs_bnr');

$this->db->order_by($sidx, $sord);

//$this->db->limit(30);

$total_rows = $this->db->get()->result();

//funcția get_rows_json a fost prezentata mai sus

return $this->genjson->get_rows_json($total_rows, $request_data);

}

În partea de View, la afișarea paginilor, se folosește în mai multe locuri controlul grid jqGrid. Pentru încărcarea lui în pagină, el trebuie sa fie definit în partea de html a paginii, de exemplu:

</<div>

Pe urma urmează partea în care controlul jqGrid este populat folosind apeluri javascript Ajax.

jQuery("#mygrid").jqGrid({

url:'<?php echo base_url(); ?>cursbnr/getJson',

datatype: "json",

colNames:['id','curs','data'],

colModel:[

{name:'id',index:'id',hidden:true},

{name:'curs',editable:true, index:'curs', width:100,editrules:{required:true},

editoptions: {

defaultValue: '<?php echo $cursbnr; ?>'}

},

{name:'data',editable:true, index:'data', width:100,editrules:{required:true},

editoptions: {

size: 12,

maxlengh: 12,

defaultValue: myd,

dataInit: function(element) {

$(element).datepicker({dateFormat: 'yy-mm-dd', autoOpen: false})

}

}}

],

rowNum:50,

rowList:[10,20,30],

pager: '#pagernav',

width: "100%",

height: 400,

loadonce: true,

sortname: 'data',

viewrecords: true,

sortorder: "desc",

caption:" Burs BNR ",

editurl:"<?php echo base_url(); ?>cursbnr/edit",

loadComplete: function (data) {

// ….

}

});

jQuery("#mygrid").jqGrid('navGrid','#pagernav',

{edit:true,add:true,del:true},

{height:"100%",width: 700,reloadAfterSubmit:false,closeAfterEdit:true}, // edit options

{height:"100%",reloadAfterSubmit:false,closeAfterAdd:true}, // add options

{reloadAfterSubmit:false}, // del options

{} // search options

);

Controlul jqGrid se populează cu date la inițializarea paginii când se face un apel Ajax către URL-ul definit în obiect la parametrul „url”. Răspunsul trebuie sa fie în format JSON, respectând o anumită structură (mai sus este prezentat un exemplu de răspuns JSON). Controlul permite mai multe setări privind modul de afișare, permite activarea de operații de adăugare sau editare automate, astfel ca nu mai trebuie scris cod pentru aceste operații. După operațiile de adăugare sau modificare se face apel automat javascript către un url specificat. Acest apel Ajax se poate seta să se facă la modificarea unui rând din grid sau la modificarea unei celule a gridului.

Meniu aplicație

Meniul aplicației se împarte în 4 categorii principale: Proiectare, Finanțe, Configurare și Administrare. În funcție de rolul pe care îl are un utilizator în aplicație vor apărea doar anumite opțiuni sau categorii din meniu.

Modul clienți

Modulul ține evidența clienților, se păstrează informațiile necesare pentru diverse funcționalități ale aplicației, având asigurate operațiile de update/delete/insert . Tot de aici se pot vizualiza proiectele aferente fiecărui client.

Modul proiecte

Este unul dintre cele mai importante părți ale aplicației, aici se ține evidența proiectelor, afișarea se face în funcție de anul selectat. Se permite filtrarea in tabel după diverse criterii cum ar fi client, denumire proiect, status proiect si altele si altele. In funcție de status, proiectele sunt afișate colorat diferit, astfel cele oprite sunt afișate cu roșu, cele in lucru sunt afișate cu albastru iar cele finalizate sunt cu verde. Pentru fiecare proiect se poate deschide o fereastră cu detalii despre fiecare proiect, in care se vizualizează informațiile detaliate privind costurile defalcate și încasările aferente proiectului. În pagina sunt 5 secțiuni :

Date proiect , unde sunt afișate informații generale despre proiect: beneficiar, adresa beneficiar, obiectiv, amplasament, AC (autorizație construcție),

Stadiu proiect, in care apare stadiul proiectului, valoare proiect, sume încasate, rest de plată, observații, se poate lista sau adăuga pentru monitorizare status la primărie.

Documentații – apar cheltuielile defalcate cu documentațiile proiectului. La rubrica avize se calculează suma de la secțiunea de “Taxe și avize”.

Taxe și avize – se afișează detaliat cheltuielile proiectului pentru taxe și avize. Sunt peste 30 de astfel de tipuri de taxe și avize.

Cheltuieli – apar defalcate cheltuielile proiectului pe personal sau colaboratori

Încasări – apar încasările efectuate pentru proiect, si data in care a avut loc plata

Utilizatorul poate sa introducă sau sa modifice foarte simplu valorile afișate, modul de lucru este asemănător cu introducerea datelor intr-o foaie de calcul Excel. După introducere datelor, se declanșează un eveniment astfel că se va face un apel Ajax care va face actualizarea datelor în baza de date. Taxele sau sumele încasate se pot introduce în lei sau în euro. De asemenea pentru fiecare categorie de taxe se pot configura din aplicație ce rubrici sa apară (Meniu -> Configurare -> Configurare fișa proiect). Toate sumele introduse apar automat în registrul de casă (Meniu -> Finanțe -> Registru de casă)

Modul documentații proiecte

Permite vizualizarea și editarea statusului privind avizele unui proiect (Meniu -> Proiectare -> Status Proiect). Sunt mai multe astfel de avizări care trebuie sa fie aprobate cum ar fi avizele de la primărie, electrica, Apa Canal , salubritate, PSI si multe altele. Sunt peste 40 de astfel câmpuri de avize sau diverse documentații care trebuie sa fie completate pentru fiecare proiect. Tot acest modul permite și listarea documentațiilor aferente fiecărui proiect. Se face un export din aplicație într-un fișier Excel care va fi sursă pentru fișierele word existente pentru documentații. Fișierele word conțin template-ul de listat, ele sunt diferite pentru fiecare instituție care va face avizarea. Fișierele word folosesc etichetele din fișierul Excel exportat.

Modulul status primărie

Acest modul permite sincronizarea statusului unui proiect cu statusul pe care îl are în baza de date a primăriei Cluj. Site-ul primăriei din Cluj pune la dispoziția utilizatorilor posibilitatea de a afla în ce stadiu și la ce compartiment din primărie se află un anumit proiect. Aplicația face automat sincronizarea proiectului cu statusul afișat de site-ul primăriei și aduce informațiile relevante despre cerere. Practic se face o prelucrare a informației pe care o afișează site-ul la o interogare web făcută de aplicație. Pentru o firmă de proiectare cu mai multe proiecte este dificil sa intre pe fiecare proiect în parte ca sa verifice în ce stadiu este proiectul. Printr-un simplu click se poate afla statusul pentru toate proiectele sau statusul unui singur proiect.

Pentru a apela pagina web a primăriei se folosește clasa PHP curl și se face un apel https astfel :

$url="https://www.e-primariaclujnapoca.ro/registratura/nrinreg.php";

$ch = curl_init($url);

curl_setopt($ch, CURLOPT_POST, true);

$request_params=array(

'Nr'=>$Nr,

'Zi'=>$Zi,

'An'=>$An,

'Luna'=>$Luna,

'Nume'=>$Nume

);

$a['error'] = false;

$a['msg'] = "";

curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($request_params));

curl_setopt($ch, CURLOPT_FOLLOWLOCATION, false);

curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

curl_setopt($ch, CURLOPT_PORT, 443);

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);

$responseHtml = curl_exec($ch);

curl_close($ch);

Răspunsul primit, în format html, este parsat cu ajutorul librariei PHP simplehtmldom (http://sourceforge.net/projects/simplehtmldom/). Cu ajutorul acestei librării răspunsul HTML primit se încarcă într-un obiect PHP de unde de poate parcurge mai ușor. Codul PHP pentru această funcție este :

$table = array();

$html=str_get_html($responseHtml);

foreach($html->find('tr') as $row) {

$DataVen = $row->find('td',0)->plaintext;

$OraVen = $row->find('td',1)->plaintext;

$Sursa = $row->find('td',2)->plaintext;

$DataTrim = $row->find('td',3)->plaintext;

$OraTrim = $row->find('td',4)->plaintext;

$Destinatia = $row->find('td',5)->plaintext;

$ModRez = $row->find('td',6)->plaintext;

$Observatii= $row->find('td',7)->plaintext;

array_push($table,array($this->myReplaceStr($DataVen." ".$OraVen),

$this->myReplaceStr($Sursa),

$this->myReplaceStr($DataTrim." ".$OraTrim),

$this->myReplaceStr($Destinatia),$ModRez));

}

return $table;

Funcția din libraria simplehtmldom care face parsarea din format HTML este str_get_html, după care se poate parcurge tabela primită folosind metoda “find” al obiectului rezultat.

Modulul Registru casa

Arată detaliat plățile si încasările avute și permite introducerea sau ștergerea de înregistrări. Se poate selecta doar o anumită lună iar la introducere se pot face diverse validări pentru a verifica daca informația este corect introdusă. De asemenea utilizatorul are posibilitatea sa marcheze că plata a fost verificată. Aici se pot introduce atât plățile cât și încasările. De asemenea tipurile de plați se pot configura din meniu Configurare -> Tipuri plăți/Încasări. Fiecare tip de plata sau de încasare permite configurarea de subcategorii, care vor apărea automat și se vor putea selecta in câmpul de explicație.

Configurare

Permite configurarea pentru diverși parametri pentru aplicație. Astfel se poate configura pentru plați sau încasări cum sa fie defalcate acestea. Fiecare categorie introdusă poate sa fie folosită pentru plăți, pentru încasări sau pentru ambele categorii. Categoria poate sa aibă subcategorii și se poate seta ca la culegerea unei plați sau încasări subcategoria să fie obligatorie sau nu.

Administrare utilizatori și roluri

Permite adăugarea de utilizator noi și modificare rolurilor unui utilizator. Rolurile definite sunt ADMIN, MANAGER si USER. În funcție de rol userul va avea acces la anumite funcționalități ale aplicației.

Securitate

Pentru a se asigura toate cerințele de securitate ale aplicației ea ar trebui sa fie accesată folosind protocolul HTTPS, asta înseamnă că serverul pe care este instalată ar trebui sa permită acest lucru. Aplicația este folosită pe un server Apache versiune 2.2 cu PHP versiune 5.3.8 dar poate fi instalată și pe alte servere HTTP.

Parolele utilizatorilor sunt ținute în format SHA256 în baza de date și sunt trimise tot criptat de către aplicație. Generarea hash-ul pentru parolă se face client-side, în browser, folosind javascript, înainte de a trimite verificarea către server. Pentru generarea hash-ului se folosește biblioteca javascript crypto-js.

Servicii web expuse de aplicația web

Serviciile web expuse sunt accesate din clasa web de tip controller wsexecute. URL catre webservice are urmatorul format :

http://<<server>>/admdoc/wsexecute/<operatie>/<parametrii separati prin / >

Exemplu :

http://10.148.1.16/admdoc/wsexecute/listaproiecte/2014/cfcd208495d565ef66e7dff9f98764da

Sunt expuse următoarele servicii web:

Aplicația mobilă

Descrierea modului de funcționare

Aplicația este dezvoltata folosind platforma jQuery mobile. Acest lucru îi permite sa fie compatibilă cu mai toate platformele mobile, dezavantajul este ca nu are acces la toate resursele device-ului și rulează mai încet decât o aplicație nativă. Dar în această lucrare scopul este de a arată cum se pot folosi serviciile web de către o aplicație mobilă, asta însemnă că vom folosi resurse externe și mai puțin cele interne ale device-ului. Pentru accesarea resurselor interne se pot folosi funcționalitățile oferite de platforma PhoneGap. Aplicația mobilă accesează servicii web, expuse de către aplicația principala, serviciile web sunt apelate prin internet așa că viteza conexiunii la internet este un factor foarte important în funcționarea aplicației. Prin intermediul serviciilor web aplicația mobilă aduce pe dispozitivul mobil informațiile din aplicația principală și permite modificări asupra datelor.

O problemă care apare la folosirea unui webservice din javascript este așa numită problemă Cross-Origin Resource Sharing (CORS), care se întâlnește in javascript atunci când se apelează o resursă din alt domeniu. Pentru a permite apelarea serviciile web prin ajax se configurează in serverul Apache:

Header set Access-Control-Allow-Origin "*"

Header add Access-Control-Allow-Headers "origin, x-requested-with, content-type"

Alta soluție este să se modifice răspunsul serviciilor web în format JSONP. Formatul JSON conține în plus față de JSON și numele funcției javascript.

//JSON

{"name":"Popescu","id":5}

//JSONP

func({"name":" Popescu ","id":5});

Metoda cu apel JSONP înseamnă ca va trebui să se interpună un proxy (servlet, JSP, script, etc) care va modifica răspunsul trimis de web service în formatul JSONP .

Structura unei pagini de jQuery este următoarea:

<!DOCTYPE html>

<html>

<head>

<title>AdmDOC</title>

</style>

$(document).on("pageinit", function() {

//..

console.log("pageinit");

$('input').bind('keypress keydown keyup', function(e) {

if (e.keyCode == 13) {

e.preventDefault();

}

});

$(document).on('pagebeforeshow', '#mainpage', function() {

// …

});

</script>

</head>

<body>

</div>

<h3>Logout</h3>

</div>

</div>

<h3>AdmDoc</h3>

<a class="ui-btn-right" href="menu.html" data-icon="grid" >Meniu</a>

</div>

</body>

</html>

Fiecare pagină de html poate să conțină mai multe pagini mobile, marcate prin tag-ul HTML <div data-role="page" (<div data-role="page" id="mainpage" data-theme="a">) . La definirea unei pagini html se va specifica și tema paginii, adică ce style dorim pentru pagina respectivă (ex: data-theme="a"). În cadrul unei pagini mobile avem definite zona de header (<div data-role="header">), de content(<div data-role="content">) și de footer (<div data-role="footer" data-position="fixed" >).

Securitate aplicației mobile

Aplicația mobila apelează servicii web expuse de către aplicația principală, serviciile fiind expuse prin internet. Pentru o securitatea mai bina apelul se poate face securizat prin https. Aplicația principală expune un web serviciu de autentificare pe baza de user și parola, sau UUID aplicație, iar web serviciul va întoarce un token care va putea fi folosit de către aplicația mobilă. Dacă utilizatorul apelează prima dată aplicația, el va fi dus în pagina de login, unde utilizatorul va completa user și parola. Aplicația va transmite către serviciul web expus pentru verificare în plus și un id unic de aplicație – UUID (Universal Unique Identifier), prin care se va identifica în mod unic dispozitivul de pe care s-a lansat interogarea. Dacă verificarea este cu succes, serviciul web v-a întoarce un token, care va fi folosit pentru interogarea serviciilor web. La orice apel de web service se va transmite tokenul respectiv care va fi verificat de către serviciul web.

Funcționalități

Aplicația mobilă are următoarele funcționalități:

Afișează lista proiectelor pentru un anumit an.

Afișează informații despre statusul unui proiect la primărie. Permite actualizarea datelor conform site-ului primăriei

Informații despre registru de casă. Permite modificarea de plați și încasări culese.

Modul Proiecte

Afișează lista proiectelor pentru un anumit an. Permite filtrarea după număr proiect sau nume beneficiar. Filtrarea este asigurată automat de jQuery mobile pentru controlul de tip listă folosit. La fiecare proiect se poate deschide detaliile privind proiectul: documente, cheltuieli, taxe și avize, încasări proiect. Pentru afișarea listei de proiecte se apelează web serviciul listaproiecte iar la afișarea detaliată a unui proiect se apelează serviciul web proiectcateg.

Lista se populează într-un control de tipul list care este definit astfel:

Acest control va avea automat filtru (data-filter=true) si va permite să se restrângă (data-role="collapsibleset"). Datele se încarcă prin apel ajax la evenimentul “pagebeforeshow” astfel:

$(document).on('pagebeforeshow', '#page1', function() { …. }.

Informația este afișată dinamic astfel:

function listproiect(pan) {

$.ajax(

{

url: vserver + "/listaproiecte/" + pan + "/"+token,

cache: false,

type: "GET",

data: {},

contentType: "application/json; charset=utf-8",

crossDomain: true,

error: function(XMLHttpRequest, textStatus, errorThrown) {

alert("Err code:" + XMLHttpRequest.status + "; Obj:" + XMLHttpRequest.statusText + "; Ajax Err:" + textStatus + "; Ajax Msg:" + errorThrown);

},

success: function(data, textStatus) {

{

$("#listmasini").empty();

var shtml = '';

$.each(data, function(i, theItem) {

var sopt = theItem.proiect_nr + " " + theItem.nume;

var vid = theItem.id;

if (!vid){

window.location="mainpage.html";

return;

}

var stmp = '<li data-role="collapsible" data-iconpos="right" data-inset="false">';

stmp = '<div id="listinforev"' + vid + ' vid=' + vid + ' data-role="collapsible">';

stmp += ' <h2>' + sopt + '</h2>';

var str = theItem.obiectiv;

str = str.replace(/\n/g, '<br />');

stmp += ' <p> <b>Obiectiv:</b>' + str + '</p>';

str = theItem.status;

stmp += ' <p><b>Status :</b>' + str + '</p>';

stmp += '<input id="btnview_' + vid + '" vid="' + vid + '" type="button" value="Deschide" data-role="button" data-inline="true" class="ui-btn ui-btn-b ui-shadow ui-corner-all" data-theme="b" />';

stmp += '</div>';

shtml += stmp;

});

$('#listmasini').append(shtml);

$('#listmasini').collapsibleset('refresh');

addEventClickSubmitProiect();

}

});

}

Pagina de proiecte arată in felul următor:

Modul status primărie

Afișează în ce status se află un proiect la primărie. Se apelează un web serviciu care întoarce statusul proiectelor la primărie, serviciul web aduce statusul proiectelor din bază de date a aplicației. Utilizatorul are posibilitatea să facă refresh la toate proiectele sau doar la un singur proiect și atunci se va interoga site-ul primăriei și se va actualiza informația în baza de date. După ce se face interogarea cu site-ul primăriei aplicația va actualiza informația din pagina.

Informația este afișată dinamic apelând prin ajax într-un control de tip table definit astfel:

Încărcarea se face la afișarea paginii. la evenimentul pagebeforeshow, apelând webservice statusprimarie.

Modul registru de casă

Arată în aplicația mobilă informațiile din registrul de casă. Sunt arătate plățile si încasările aferente proiectelor precum și detalii despre acestea. Afișarea se face dinamic folosind apeluri ajax din jQuery. Se apelează serviciul web registrucasa. În codul HTML sunt definite 2 pagini, una în care se afișează lista cu înregistrările din registru de casă și a doua în care se pot modifica informațiile pentru anumită înregistrare.

Trecerea de la o pagina la alta se face folosind comanda JQuery mobile $.mobile.changePage("#page2"); Modificările sunt trimise care serviciul web regcasa_update, prin apel de tip POST.

Datele sunt trimise în format JSON din javascript prin apel AJAX si sunt citite de către serviciul web.

Codul prin care se apelează webserviciul este :

var data = {};

data["id"] = vidrec;

data["categ"] = $("#edt_categ").val();

data["data"] = $("#edt_data").val();

….

data["plata_ron"] = $("#edt_plata_ron").val();

data["plata_euro"] = $("#edt_plata_euro").val();

$.ajax(

{

url: vserver + "/regcasa_update/" +token,

cache: false,

type: "POST",

data: JSON.stringify(data),

contentType: "application/json; charset=utf-8",

dataType: "json",

crossDomain: true,

error: function(XMLHttpRequest, textStatus, errorThrown) {

alert("Err code:" + XMLHttpRequest.status + "; Obj:" + XMLHttpRequest.statusText + "; Ajax Err:" + textStatus + "; Ajax Msg:" + errorThrown);

},

success: function(data, textStatus) {

{

……..

}

});

Pentru a citi in webserviciu parametrii JSON trimisi se procedează astfel:

public function regcasa_update($request_data){

$json = file_get_contents('php://input');

$obj = json_decode($json);

log_message('error', " inc ron ".$obj->incasare_ron );

$data = array(

"incasare_ron" =>$obj->incasare_ron ,

"incasare_euro" => $obj->incasare_euro ,

"plata_ron" => $obj->plata_ron ,

"plata_euro" =>$obj->plata_euro

);

$this->db->where('id', $obj->id);

return $this->db->update('registru_casa', $data);

}

Paginile pentru registrul de casă arată în felul următor:

Concluzii

Serviciile web sunt tot mai folosite in arhitectura distribuită, ele pot sa servească diverși clienți dezvoltați în diferite limbaje de programare și pe diferite platforme astfel că ele pot să fie folosite cu destulă ușurință de către aplicațiile mobile.

Lucrarea prezintă cele mai folosite tipuri de servicii web și arată cele mai importante caracteristici asociate acestora. Indiferent că sunt servicii de tip SOAP sau REST, deoarece se folosesc in mediul distribuit, ele trebuie să fie bine documentate. Chiar dacă este vorba de un serviciu de tip SOAP unde din WSDL se poate deduce formatul mesajului trimis nu se cunoaște cum trebuie trimisă informația. De exemplu un serviciu web ar putea sa primească o lista de atribute de tip <nume parametru> – <valoare parametru> si atunci nu se știe ce ar trebui sa conțină mesajul. Ele sunt foarte răspândite, astfel că toate limbajele de programare moderne ar trebui să lucreze cu ele. De multe ori serviciile web sunt folosite la interconectarea diverselor aplicații dezvoltate de dezvoltatori diferiți, astfel că este foarte important să se specifice exact ce fel de servicii web vor fi expuse și ce fel de standarde folosesc.

Serviciile web de tip REST sunt mai des folosite in mediul web si de către aplicațiile mobile pe când cele de tip SOAP sunt folosite in mediul Enterprise. Cele de tipul SOAP permit mai multe extensii care pot fi folosite in diferite contexte pe când cele de tip REST sunt mai ușor de folosit și traficul de date este mai redus.

În lucrarea de față se insistă pe partea practică, sunt date exemple de creare și de utilizare a serviciilor web în limbaje de programare cunoscute de mulți dezvoltatori, cum ar fi Java, Javascript și PHP și diferite medii de dezvoltare.

Sunt prezentate diverse moduri cum se poate dezvolta un serviciul web folosind diverse tehnologii si cum poate fi accesat de diferiți clienți. Se arată modul cum poate să fie apelat un serviciu web din mediul nativ Android si IOS, cele mai folosite platforme mobile sau din mediul HTML5, de unde poate sa fie portat în diverse platforme de operare.

Aplicațiile mobile dezvoltate în mediul nativ funcționează mai bine, sunt mai rapide, pe când cele dezvoltate folosind HTML5 sau tehnologii cross-platform sunt mai ușor de dezvoltat și mai portabile.

Partea practică conține o aplicație complexă, folosită cu succes în activitatea unei firme de proiectare în construcții, aplicația fiind construită folosite tehnologii noi, des folosite în dezvoltarea aplicațiilor mobile și web. Aplicația mobilă este construită pe baza tehnologiei jQuery Mobile și folosește servicii web de tip REST expuse de către aplicația principală. Cu ajutorul platformei PhoneGap se generează pachetul care se poate instala pe smartphone.

Acronime

AJAX – Asynchronous JavaScript and XML.

CSV – Comma-separated values

HTTP – HyperText transport Protocol

HTML – HyperText Markup Language

JSON – JavaScript Object Notation

JSONP – JavaScript Object Notation Padding

IDE – integrated development environment

REST – Representational State Transfer

XML – eXtensible Markup Language

SOAP – Simple Object Acess Protocol

SSL – Secure Sockets Layer

WSDL – Web Service Description Language

UDDI – Universal Description and Discovery

UUID – Universal Unique Identifier

URI – Uniform Resource Identifier

Bibliografie

Leonard Richardson, RESTful Web Services, O'Reilly, 2007

James Snell, Doug Tidwell, Pavel Kulchenko, Programming Web Services with SOAP, O'Reilly, 2001

Apple, Using the Web Services Core Framework, online la https://developer.apple.com/library/mac/documentation/Networking/Conceptual/UsingWebservices/Tasks/Tasks.html, accesat mai 2015

CodeIgniter, online la „http://www.codeigniter.com/user_guide/” accesat mai 2015

Steve Francia, „REST Vs SOAP, The Difference Between Soap And Rest”, online la „http://spf13.com/post/soap-vs-rest”, accesat mai 2015

jQuery Mobile, online la https://jquerymobile.com/, accesat mai 2015

Hamdy Ghanem, Send and Receive JSON between Android and PHP Web Service, online la „http://www.codeproject.com/Articles/267023/Send-and-receive-json-between-android-and-php”, accesat mai 2015

Mark Roland, How to Build a RESTful API Web Service with PHP, online la “http://markroland.com/blog/restful-php-api/”, accesat iunie 2015

RapidValue, How to Choose the Right Architecture, online la „http://rapidvaluesolutions.com/whitepapers/how-to-choose-the-right-architecture.html”, accesat la mai 2015