SlideShare a Scribd company logo
SVILUPPO DI SERVIZI REST PER
           ANDROID

          Ovvero tutto quello che abbiamo
        imparato sviluppando servizi REST per
                 applicazioni Mobile




Luca Masini - @lmasini
GTUG Firenze
Agenda
•   Obiettivi
•   Architettura e infrastruttura
•   REST e Livello 3
•   Frameworks
•   Multiplatform
•   Security
•   Versioning
•   Caching
Obiettivi
• I servizi coprono:
   – Aree informative
   – Asset Digitali
   – Ricerche su basi dati enterprise
   – Servizi online
per un totale di circa 30 end-point
Obiettivi
• Realizzare servizi usabili da client
  diversi...
    come sistema operativo
    come layout grafico
    come risorse a disposizione


• Non si tratta quindi di API REST, ma di
  servizi per un'applicazione specifica
Architettura e infrastruttura
• Internet è sia architettura che infrastruttura
• Il supporto tecnologico è diffuso (Java, .NET,
  Python..) per la realizzazione di RESTful services
• Cloud non ha problemi di banda (ma i parametri
  TCP/IP devono essere ottimizzati per il 3G)
• La scalabilità è assicurata (e dunque le
  performance) da:
   – Massimo disaccoppiamento (un link!)
   – Caching (anche solo con 304 !!)
   – Proxy
REST e livello 3
• Il RMM definisce quattro livelli di maturità a seconda di
  quanto si usino HTTP, URI ed Hypermedia, partendo dallo
  zero per i servizi che non usano alcuno di questi
  (tipicamente SOAP !)


• Un servizio di “maturità 3” ha la caratteristica di:
   – Indirizzare la risorsa tramite la URL
   – Usare i verbi HTTP per indicare l'azione sulla risorsa
   – Esporre una rappresentazione in grado di "guidare" lo
     sviluppatore o la macchina a stati finiti verso
     l'esplorazione del sistema (HATEOAS)
Frameworks Server
• La realizzazione di RESTful services è assicurata da
  ogni tecnologia server-side:
   – Windows Communication Foundation (WCF)
     per .NET
   – Il mondo Java ha una specifica proprio indirizzata
     a REST, ovvero JAX-RS (ora in corso di definizione
     la 2.1) e due implementazioni maggiori:
       • RESTEasy di Jboss
       • Jersey (la RI)
  – Spring implementa REST tramite i RequestMapper
    del framework MVC
Frameworks Client
• Chiamare i servizi REST con Apache
  HTTP Client è come sviluppare Servlet
  partendo dal socket !!

• Possiamo usare lo stesso idioma del
  server con librerie come resteasy-
  client-mobile
Frameworks Client
Definizione servizio:
@Path("/1/boards")
public interface BoardService {
    @GET
    @Produces(MediaType.APPLICATION_JSON)
    @Path("/{boardid}/lists")
    List<CardContainer> findListsForBoard(@PathParam("boardid") String boardid,
                                            @QueryParam("key") String key);
}


invocazione del servizio:
BoardService service = ProxyFactory.create(BoardService.class,"https://api.trello.com");
List<CardContainer> lists = service.findListsForBoard(boardId,
SplashScreenActivity.testKey);
Multiplatform
• Realizzare servizi per piattaforme diverse
  comporta la risoluzione di alcuni problemi:
   – Diversificazione dell'informazione inviata al
     client in base alle sue "capacità" (ad es.
     risoluzione/dimensione schermo)
   – Modalità diverse di rendering e
     rappresentazione (ad es. i volantini)
   – Wireframe diversi per versioni HD e non,
     che però non giustificano nuovi end-point
Security
• Più che la sicurezza lato end-user,
  comunque importante, il focus è stato
  spostato sull'evitare che applicazioni
  terze parti possano usare questi servizi
  REST

• E' l'antitesi di quello che tutti fanno
  oggi, ovvero rendere disponibili i dati
Security
// Carica certification authority in formato BKS
InputStream clientTruststoreIs =
     getResources().openRawResource(R.raw.certification_authority);
KeyStore clientCertificate = KeyStore.getInstance("BKS");
clientCertificate.load(clientTruststoreIs, "verysecretpassword".toCharArray());

System.out.println("Loaded certification authority: " + clientCertificate.size());

// Carica client certificate
InputStream keyStoreStream = getResources().openRawResource(R.raw.client_certificate);
KeyStore keyStore = KeyStore.getInstance("pkcs12");
keyStore.load(keyStoreStream, "Another Super Secret Password".toCharArray());

System.out.println("Loaded client certificates: " + keyStore.size());

// Crea la SSLSocketFactory con
SSLSocketFactory socketFactory =
    new SSLSocketFactory(keyStore, "trust",clientCertificate);

// Configura parametri chiamata HTTP
HttpParams params = new BasicHttpParams();
HttpProtocolParams.setVersion(params, HttpVersion.HTTP_1_1);
HttpProtocolParams.setContentCharset(params, "UTF-8");
HttpProtocolParams.setUseExpectContinue(params, true);
HttpProtocolParams.setUserAgent(params, "CompanyApp 1.0");
Security
// Facciamo un ESSENZIALE pool per le connessioni su questo socket !!!!
ConnPerRoute connPerRoute = new ConnPerRouteBean(12);
ConnManagerParams.setMaxConnectionsPerRoute(params, connPerRoute);
ConnManagerParams.setMaxTotalConnections(params, 20);

// Set timeout
HttpConnectionParams.setStaleCheckingEnabled(params, false);
HttpConnectionParams.setConnectionTimeout(params, 20 * 1000);
HttpConnectionParams.setSoTimeout(params, 20 * 1000);
HttpConnectionParams.setSocketBufferSize(params, 8192);

// Non seguo redirect
HttpClientParams.setRedirecting(params, false);

// Registro https con il nostro SSLSocketFactory
SchemeRegistry schReg = new SchemeRegistry();
schReg.register(new Scheme("https", socketFactory, 443));
ClientConnectionManager conMgr = new ThreadSafeClientConnManager(params, schReg);
DefaultHttpClient sClient = new DefaultHttpClient(conMgr, params);

// Finalmente faccio sta benedetta chiamata
HttpGet httpGet = new HttpGet("https://mobile.company.it/services/store/STOREID");
HttpResponse response = sClient.execute(httpGet);
HttpEntity httpEntity = response.getEntity();
Versioning
• L'evoluzione di un'app porta ad avere distribuiti
  client di versioni diverse sui device degli utenti



• Le nuove caratteristiche portano a sviluppare
  nuovi servizi
Versioning
• La criticità si ha quando servizi esistenti devono
  tornare dati nuovi rimanendo compatibili !!!!!!


  {
      sigla: "NEG",
      descrizione: "Negozio",
      indirizzo: "Via dei Servizi REST",
      cap: "50135",
      comune: "Firenze",
      provincia: "FI",

      UrlDettaglio: “https://url.to.detail” // <== Nuovo attributo
  }
Versioning
• La criticità si ha quando servizi esistenti devono
  tornare dati nuovi rimanendo compatibili !!!!!!


  {
      sigla: "NEG",
      descrizione: "Negozio",
      indirizzo: "Via dei Servizi REST",
      cap: "50135",
      comune: "Firenze",
      provincia: "FI",

      UrlDettaglio: “https://url.to.detail” // <== Nuovo attributo
  }
Versioning
• Il problema del versioning si può mitigare
  tramite un corretto uso di JSON, delle API/User-
  Agent e scrivendo fin da subito client che sono
  molto "permissivi" a riguardo dei dati che
  ricevono

  @SourceServiceVersions(
       @SourceServiceVersion(versionTag = VersionTag.HD, targetMethod = "methodForHD")
  )
  @Override
  public List<Map<String, Object>> defaultMethod(String info) {}


  @TargetServiceVersions(value = {VersionTag.HD})
  public List<Map<String, Object>> methodForHD(String info) {}
Caching
• HTTP ed Internet hanno già implicito il concetto di caching, che
  deve essere implementato però dai nostri servizi e dai nostri
  client, rispettando i verbi HTTP e gli header di caching.


• Purtroppo le librerie HTTP delle piattaforme mobile mancano di
  molti dei concetti che i browser implementano da decenni


• Vista l'alta latenza del 3G è importante pensare ad
  implementare anche back-end caches dei nostri servizi
  (memcached) o l'uso di back-end adatti al cloud (NoSQL)
Domande ??




Luca Masini - @lmasini
GTUG Firenze
Firenze GTUG
           Google Technology User Group - Firenze



 Site: http://sites.google.com/site/firenzegtug/
 Blog: http://firenze-gtug.blogspot.it/
 Group: firenze-gtug@googlegroups.com

...presto GDG
Google Developer Group

More Related Content

Similar to SVILUPPO DI SERVIZI REST PER ANDROID

OCP Paas_ultima
OCP Paas_ultimaOCP Paas_ultima
OCP Paas_ultima
opencityplatform
 
Designing with microservices - Daniele Mondello
Designing with microservices - Daniele MondelloDesigning with microservices - Daniele Mondello
Designing with microservices - Daniele Mondello
Daniele Mondello
 
Alla scoperta di gRPC
Alla scoperta di gRPCAlla scoperta di gRPC
Alla scoperta di gRPC
Andrea Dottor
 
I Love Cloud by Soluzioni Futura
I Love Cloud by Soluzioni FuturaI Love Cloud by Soluzioni Futura
I Love Cloud by Soluzioni Futura
Soluzioni Futura
 
I Love Cloud by Soluzioni Futura
I Love Cloud by Soluzioni FuturaI Love Cloud by Soluzioni Futura
I Love Cloud by Soluzioni Futura
Valerio Versace
 
Cert03 70-486 developing asp.net mvc 4 web applications
Cert03   70-486 developing asp.net mvc 4 web applicationsCert03   70-486 developing asp.net mvc 4 web applications
Cert03 70-486 developing asp.net mvc 4 web applicationsDotNetCampus
 
Del furia signalr-to-the-max
Del furia   signalr-to-the-maxDel furia   signalr-to-the-max
Del furia signalr-to-the-maxDotNetCampus
 
SIGNALR TO-THE-MAX: VERSO IL WEB ED OLTRE!
SIGNALR TO-THE-MAX: VERSO IL WEB ED OLTRE!SIGNALR TO-THE-MAX: VERSO IL WEB ED OLTRE!
SIGNALR TO-THE-MAX: VERSO IL WEB ED OLTRE!
DotNetCampus
 
Signal r to the-max
Signal r to the-maxSignal r to the-max
Signal r to the-maxDotNetCampus
 
Meetup Fluent Design e Progressive Web App
Meetup Fluent Design e Progressive Web AppMeetup Fluent Design e Progressive Web App
Meetup Fluent Design e Progressive Web App
dotnetcode
 
Meetup Progressive Web App
Meetup Progressive Web AppMeetup Progressive Web App
Meetup Progressive Web App
dotnetcode
 
REST API fantastiche e dove trovarle
REST API fantastiche e dove trovarleREST API fantastiche e dove trovarle
REST API fantastiche e dove trovarle
Marco Breveglieri
 
Virtual Agency
Virtual AgencyVirtual Agency
Virtual Agency
Enrico Micco
 
Swagger per tutti
Swagger per tuttiSwagger per tutti
Swagger per tutti
Nicolò Carandini
 
e-SUAP - General software architecture (Italiano)
e-SUAP - General software architecture (Italiano)e-SUAP - General software architecture (Italiano)
e-SUAP - General software architecture (Italiano)
Sabino Labarile
 
Applicazioni web based
Applicazioni web basedApplicazioni web based
Applicazioni web based
Marco Liverani
 
.NET Microservices
.NET Microservices.NET Microservices
.NET Microservices
Luca Congiu
 
Back to the Future: Migrare da WebForm ad ASP.NET Core gradualmente
Back to the Future: Migrare da WebForm ad ASP.NET Core gradualmente Back to the Future: Migrare da WebForm ad ASP.NET Core gradualmente
Back to the Future: Migrare da WebForm ad ASP.NET Core gradualmente
Andrea Dottor
 
Novità di Asp.Net 4.0
Novità di Asp.Net 4.0Novità di Asp.Net 4.0
Novità di Asp.Net 4.0
Gian Maria Ricci
 
Dal requisito all'implementazione @ CD2010
Dal requisito all'implementazione @ CD2010Dal requisito all'implementazione @ CD2010
Dal requisito all'implementazione @ CD2010
Mauro Servienti
 

Similar to SVILUPPO DI SERVIZI REST PER ANDROID (20)

OCP Paas_ultima
OCP Paas_ultimaOCP Paas_ultima
OCP Paas_ultima
 
Designing with microservices - Daniele Mondello
Designing with microservices - Daniele MondelloDesigning with microservices - Daniele Mondello
Designing with microservices - Daniele Mondello
 
Alla scoperta di gRPC
Alla scoperta di gRPCAlla scoperta di gRPC
Alla scoperta di gRPC
 
I Love Cloud by Soluzioni Futura
I Love Cloud by Soluzioni FuturaI Love Cloud by Soluzioni Futura
I Love Cloud by Soluzioni Futura
 
I Love Cloud by Soluzioni Futura
I Love Cloud by Soluzioni FuturaI Love Cloud by Soluzioni Futura
I Love Cloud by Soluzioni Futura
 
Cert03 70-486 developing asp.net mvc 4 web applications
Cert03   70-486 developing asp.net mvc 4 web applicationsCert03   70-486 developing asp.net mvc 4 web applications
Cert03 70-486 developing asp.net mvc 4 web applications
 
Del furia signalr-to-the-max
Del furia   signalr-to-the-maxDel furia   signalr-to-the-max
Del furia signalr-to-the-max
 
SIGNALR TO-THE-MAX: VERSO IL WEB ED OLTRE!
SIGNALR TO-THE-MAX: VERSO IL WEB ED OLTRE!SIGNALR TO-THE-MAX: VERSO IL WEB ED OLTRE!
SIGNALR TO-THE-MAX: VERSO IL WEB ED OLTRE!
 
Signal r to the-max
Signal r to the-maxSignal r to the-max
Signal r to the-max
 
Meetup Fluent Design e Progressive Web App
Meetup Fluent Design e Progressive Web AppMeetup Fluent Design e Progressive Web App
Meetup Fluent Design e Progressive Web App
 
Meetup Progressive Web App
Meetup Progressive Web AppMeetup Progressive Web App
Meetup Progressive Web App
 
REST API fantastiche e dove trovarle
REST API fantastiche e dove trovarleREST API fantastiche e dove trovarle
REST API fantastiche e dove trovarle
 
Virtual Agency
Virtual AgencyVirtual Agency
Virtual Agency
 
Swagger per tutti
Swagger per tuttiSwagger per tutti
Swagger per tutti
 
e-SUAP - General software architecture (Italiano)
e-SUAP - General software architecture (Italiano)e-SUAP - General software architecture (Italiano)
e-SUAP - General software architecture (Italiano)
 
Applicazioni web based
Applicazioni web basedApplicazioni web based
Applicazioni web based
 
.NET Microservices
.NET Microservices.NET Microservices
.NET Microservices
 
Back to the Future: Migrare da WebForm ad ASP.NET Core gradualmente
Back to the Future: Migrare da WebForm ad ASP.NET Core gradualmente Back to the Future: Migrare da WebForm ad ASP.NET Core gradualmente
Back to the Future: Migrare da WebForm ad ASP.NET Core gradualmente
 
Novità di Asp.Net 4.0
Novità di Asp.Net 4.0Novità di Asp.Net 4.0
Novità di Asp.Net 4.0
 
Dal requisito all'implementazione @ CD2010
Dal requisito all'implementazione @ CD2010Dal requisito all'implementazione @ CD2010
Dal requisito all'implementazione @ CD2010
 

SVILUPPO DI SERVIZI REST PER ANDROID

  • 1. SVILUPPO DI SERVIZI REST PER ANDROID Ovvero tutto quello che abbiamo imparato sviluppando servizi REST per applicazioni Mobile Luca Masini - @lmasini GTUG Firenze
  • 2. Agenda • Obiettivi • Architettura e infrastruttura • REST e Livello 3 • Frameworks • Multiplatform • Security • Versioning • Caching
  • 3. Obiettivi • I servizi coprono: – Aree informative – Asset Digitali – Ricerche su basi dati enterprise – Servizi online per un totale di circa 30 end-point
  • 4. Obiettivi • Realizzare servizi usabili da client diversi... come sistema operativo come layout grafico come risorse a disposizione • Non si tratta quindi di API REST, ma di servizi per un'applicazione specifica
  • 5. Architettura e infrastruttura • Internet è sia architettura che infrastruttura • Il supporto tecnologico è diffuso (Java, .NET, Python..) per la realizzazione di RESTful services • Cloud non ha problemi di banda (ma i parametri TCP/IP devono essere ottimizzati per il 3G) • La scalabilità è assicurata (e dunque le performance) da: – Massimo disaccoppiamento (un link!) – Caching (anche solo con 304 !!) – Proxy
  • 6. REST e livello 3 • Il RMM definisce quattro livelli di maturità a seconda di quanto si usino HTTP, URI ed Hypermedia, partendo dallo zero per i servizi che non usano alcuno di questi (tipicamente SOAP !) • Un servizio di “maturità 3” ha la caratteristica di: – Indirizzare la risorsa tramite la URL – Usare i verbi HTTP per indicare l'azione sulla risorsa – Esporre una rappresentazione in grado di "guidare" lo sviluppatore o la macchina a stati finiti verso l'esplorazione del sistema (HATEOAS)
  • 7. Frameworks Server • La realizzazione di RESTful services è assicurata da ogni tecnologia server-side: – Windows Communication Foundation (WCF) per .NET – Il mondo Java ha una specifica proprio indirizzata a REST, ovvero JAX-RS (ora in corso di definizione la 2.1) e due implementazioni maggiori: • RESTEasy di Jboss • Jersey (la RI) – Spring implementa REST tramite i RequestMapper del framework MVC
  • 8. Frameworks Client • Chiamare i servizi REST con Apache HTTP Client è come sviluppare Servlet partendo dal socket !! • Possiamo usare lo stesso idioma del server con librerie come resteasy- client-mobile
  • 9. Frameworks Client Definizione servizio: @Path("/1/boards") public interface BoardService { @GET @Produces(MediaType.APPLICATION_JSON) @Path("/{boardid}/lists") List<CardContainer> findListsForBoard(@PathParam("boardid") String boardid, @QueryParam("key") String key); } invocazione del servizio: BoardService service = ProxyFactory.create(BoardService.class,"https://api.trello.com"); List<CardContainer> lists = service.findListsForBoard(boardId, SplashScreenActivity.testKey);
  • 10. Multiplatform • Realizzare servizi per piattaforme diverse comporta la risoluzione di alcuni problemi: – Diversificazione dell'informazione inviata al client in base alle sue "capacità" (ad es. risoluzione/dimensione schermo) – Modalità diverse di rendering e rappresentazione (ad es. i volantini) – Wireframe diversi per versioni HD e non, che però non giustificano nuovi end-point
  • 11. Security • Più che la sicurezza lato end-user, comunque importante, il focus è stato spostato sull'evitare che applicazioni terze parti possano usare questi servizi REST • E' l'antitesi di quello che tutti fanno oggi, ovvero rendere disponibili i dati
  • 12. Security // Carica certification authority in formato BKS InputStream clientTruststoreIs = getResources().openRawResource(R.raw.certification_authority); KeyStore clientCertificate = KeyStore.getInstance("BKS"); clientCertificate.load(clientTruststoreIs, "verysecretpassword".toCharArray()); System.out.println("Loaded certification authority: " + clientCertificate.size()); // Carica client certificate InputStream keyStoreStream = getResources().openRawResource(R.raw.client_certificate); KeyStore keyStore = KeyStore.getInstance("pkcs12"); keyStore.load(keyStoreStream, "Another Super Secret Password".toCharArray()); System.out.println("Loaded client certificates: " + keyStore.size()); // Crea la SSLSocketFactory con SSLSocketFactory socketFactory = new SSLSocketFactory(keyStore, "trust",clientCertificate); // Configura parametri chiamata HTTP HttpParams params = new BasicHttpParams(); HttpProtocolParams.setVersion(params, HttpVersion.HTTP_1_1); HttpProtocolParams.setContentCharset(params, "UTF-8"); HttpProtocolParams.setUseExpectContinue(params, true); HttpProtocolParams.setUserAgent(params, "CompanyApp 1.0");
  • 13. Security // Facciamo un ESSENZIALE pool per le connessioni su questo socket !!!! ConnPerRoute connPerRoute = new ConnPerRouteBean(12); ConnManagerParams.setMaxConnectionsPerRoute(params, connPerRoute); ConnManagerParams.setMaxTotalConnections(params, 20); // Set timeout HttpConnectionParams.setStaleCheckingEnabled(params, false); HttpConnectionParams.setConnectionTimeout(params, 20 * 1000); HttpConnectionParams.setSoTimeout(params, 20 * 1000); HttpConnectionParams.setSocketBufferSize(params, 8192); // Non seguo redirect HttpClientParams.setRedirecting(params, false); // Registro https con il nostro SSLSocketFactory SchemeRegistry schReg = new SchemeRegistry(); schReg.register(new Scheme("https", socketFactory, 443)); ClientConnectionManager conMgr = new ThreadSafeClientConnManager(params, schReg); DefaultHttpClient sClient = new DefaultHttpClient(conMgr, params); // Finalmente faccio sta benedetta chiamata HttpGet httpGet = new HttpGet("https://mobile.company.it/services/store/STOREID"); HttpResponse response = sClient.execute(httpGet); HttpEntity httpEntity = response.getEntity();
  • 14. Versioning • L'evoluzione di un'app porta ad avere distribuiti client di versioni diverse sui device degli utenti • Le nuove caratteristiche portano a sviluppare nuovi servizi
  • 15. Versioning • La criticità si ha quando servizi esistenti devono tornare dati nuovi rimanendo compatibili !!!!!! { sigla: "NEG", descrizione: "Negozio", indirizzo: "Via dei Servizi REST", cap: "50135", comune: "Firenze", provincia: "FI", UrlDettaglio: “https://url.to.detail” // <== Nuovo attributo }
  • 16. Versioning • La criticità si ha quando servizi esistenti devono tornare dati nuovi rimanendo compatibili !!!!!! { sigla: "NEG", descrizione: "Negozio", indirizzo: "Via dei Servizi REST", cap: "50135", comune: "Firenze", provincia: "FI", UrlDettaglio: “https://url.to.detail” // <== Nuovo attributo }
  • 17. Versioning • Il problema del versioning si può mitigare tramite un corretto uso di JSON, delle API/User- Agent e scrivendo fin da subito client che sono molto "permissivi" a riguardo dei dati che ricevono @SourceServiceVersions( @SourceServiceVersion(versionTag = VersionTag.HD, targetMethod = "methodForHD") ) @Override public List<Map<String, Object>> defaultMethod(String info) {} @TargetServiceVersions(value = {VersionTag.HD}) public List<Map<String, Object>> methodForHD(String info) {}
  • 18. Caching • HTTP ed Internet hanno già implicito il concetto di caching, che deve essere implementato però dai nostri servizi e dai nostri client, rispettando i verbi HTTP e gli header di caching. • Purtroppo le librerie HTTP delle piattaforme mobile mancano di molti dei concetti che i browser implementano da decenni • Vista l'alta latenza del 3G è importante pensare ad implementare anche back-end caches dei nostri servizi (memcached) o l'uso di back-end adatti al cloud (NoSQL)
  • 19. Domande ?? Luca Masini - @lmasini GTUG Firenze
  • 20. Firenze GTUG Google Technology User Group - Firenze Site: http://sites.google.com/site/firenzegtug/ Blog: http://firenze-gtug.blogspot.it/ Group: firenze-gtug@googlegroups.com ...presto GDG Google Developer Group