Tipo Safety of Spray.io

1

Ieri ho letto un tweet denigrando Jersey con JAX-RS a causa di errori di run-time. Spray.io è stato citato nel tweet:

Not even 5 minutes using Jersey / JAX-RS and already a runtime error due to a missing annotation. That's why I like @sprayio: type safety.

link

In che modo spray.io fornisce sicurezza di tipo?

Potresti fare un esempio?

    
posta Kevin Meredith 17.05.2014 - 15:36
fonte

1 risposta

4

Ci sono diversi componenti per la sicurezza del tipo di spray. Ecco una selezione

  1. modello più o meno completo per strutture di dati HTTP che includono molte intestazioni
  2. infrastruttura di marshalling basata sulla classe type
  3. estrazione sicura dei dati nei percorsi, combinazione sicura al tipo di parti del percorso

Per spiegare ancora un po '

  1. Un modello completo per HTTP significa che dopo aver analizzato (o costruito) un messaggio HTTP segue una determinata struttura fissa e determinati invarianti sono soddisfatti. Per esempio. questo significa che l'analisi a livello utente delle intestazioni di solito non è necessaria e gli errori di runtime nel codice che si occupano di tali intestazioni possono essere in qualche modo esclusi.

  2. L'infrastruttura di (marsupio) di marshalling garantisce staticamente che i valori dei tipi di dominio possano essere convertiti in strutture di dati HTTP solo se un marshaller per quel tipo è disponibile staticamente (tramite impliciti). Ciò significa che in una rotta puoi generalmente lavorare sul livello dei tuoi tipi di dominio con tutta la logica che collega i tipi che sono nascosti nelle definizioni di Marshaller.

  3. Nella struttura del percorso di spray è possibile estrarre i valori da una richiesta. Per esempio. puoi utilizzare parameters('name.as[String], 'age.as[Int]) per accedere al parametro di query name e age di una richiesta. L'utilizzo di as[T] significa che il valore estratto verrà convertito nel tipo T in fase di esecuzione. All'interno della rotta parameters sai che name e age saranno dei tipi giusti (altrimenti spray genererà un messaggio di errore appropriato per il client).

    Le rotte di

    spray sono composte da "direttive". Ogni direttiva ha un tipo Directive[T1 :: T2 :: ... :: HNil] dove T1... sono tipi di valori che vengono estratti da una direttiva. Le direttive possono essere composte liberamente, ciò significa che invece di parameters('name.as[String], 'age.as[Int]) (che è di tipo Directive[String :: Int :: HNil] ) potresti anche scrivere parameters('name.as[String]) & parameters('age.as[Int]) . Ciò ti consente di estrarre schemi comuni nel tuo percorso nelle tue direttive personalizzate che puoi riutilizzare ovunque.

    Vedi la spray documentation on directives per ulteriori informazioni su questo argomento .

Avrebbe anche senso parlare di punti in cui lo spray non è sicuro per il tipo (alcuni di questi punti potrebbero essere risolti in futuro, altri sono inerenti all'architettura). Per es.

  • Puoi perdere l'operatore ~ mentre costruisci un percorso.
  • Può essere difficile vedere se un tipo di contenuto è consentito / generato per una rotta oppure no.
  • Attualmente è possibile non gestire una richiesta nel percorso.
  • Un servizio che "chiedi" per una risposta a una richiesta (vedi il modello di richiesta Akka) può rispondere con un tipo di messaggio inaspettato.
  • È possibile violare il protocollo dei messaggi per spruzzare attori (che è comune a tutti i flussi di messaggi con attori Akka che non è tipizzato).
  • ...
risposta data 19.05.2014 - 14:02
fonte

Leggi altre domande sui tag