WEB STORAGE: USANDO A API DO HTML5 NO

ARMAZENAMENTO DE DADOS LOCAIS DE APLICAES WEB

Resumo:
Em sistemas tipicamente distribudos cliente-servidor, nos quais as aplicaes web
se encontram, o armazenamento das informaes feito geralmente em um servidor de
aplicao ou de banco de dados. Essa organizao, entretanto, no permite que as
aplicaes web funcionem sem que elas estejam conectadas a uma rede. Entretanto, h
casos nos quais podemos querer que um aplicativo funcione sem estar conectado a uma
rede (offline) e que, assim que se conectar a uma mais tarde, possa trocar informaes com
o servidor, sincronizando os dados, por exemplo. Vrias tecnologias foram desenvolvidas
ao longo dos anos, de modo a fornecer algum tipo de suporte ao armazenamento local de
dados. Porm, a maioria delas era apenas uma soluo paliativa, no padronizada, que
dependia de um nico navegador ou da instalao de programas de terceiros (plugins).
Assim, para cobrir a falta de uma soluo padro que pudesse ser adotada mundialmente
pelos desenvolvedores web, junto com a especificao do HTML5, surge ento uma nova
tecnologia, o Web storage, a qual veremos nesse artigo.

Palavras-Chave: HTML5 Web storage; Storage API; Browser storage; Armazenamento

de dados; Aplicaes web.

Introduo
As aplicaes web so tipicamente sistemas distribudos do tipo cliente-servidor1,
cujas informaes geralmente so armazenadas no lado servidor. No entanto, existem
vrios motivos pelos quais precisamos armazenar dados no lado cliente (dados locais). Por
exemplo, podemos querer que um aplicativo continue funcionando mesmo que o usurio
1

http://pt.wikipedia.org/wiki/Cliente-servidor

no esteja conectado a uma Internet (off-line) e que, assim que ele se conectar a uma, os
dados locais sejam, ento, transmitidos de modo a serem sincronizados com aqueles que
esto armazenados no lado servidor.
Num primeiro momento, essa necessidade de armazenamento de dados locais surge
principalmente em funo das caractersticas do prprio protocolo HTTP (HyperText
Transfer Protocol), usado nas comunicaes via web. O HTTP um protocolo de
comunicao requisio-resposta sem estado (stateless). Isso significa que o protocolo
HTTP trata as comunicaes de modo independente umas das outras, no mantendo dados
e/ou informaes de estado durante mltiplas requisies-respostas. Dessa forma, uma
transao que envolve mais de uma comunicao, para ser concluda, sem uma maneira de
armazenar dados localmente, no tem como ser realizada usando-se apenas o protocolo
HTTP.
Historicamente, o cookie foi o primeiro recurso criado para a web, para fazer o
armazenamento local de pequenas quantidades de dados. Ele foi projetado para ser um
mecanismo pelo qual os sites pudessem lembrar de informaes de estado (stateful), de
modo que uma transao que envolvesse mais de uma comunicao sob o protocolo HTTP
pudesse ser concluda (p.ex. a relao de itens em um carrinho de compras, as atividades
de navegao de um usurio, informaes de login, preferncias do usurio, menus
customizveis, etc.).
A utilizao dos cookies, no entanto, apresenta alguns problemas e/ou restries:
i)

a quantidade de dados armazenados em um cookie pequena. Eles possuem

uma limitao de 4KB no mximo de dados;

ii) os dados em um cookie tem como origem apenas o servidor. O que significa
que, se quisermos armazenar dados do cliente em um cookie, precisamos
envi-los ao servidor primeiro, para que estes sejam reenviados novamente a
mquina cliente sob a fora de cookies;
iii) os cookies so includos em todas as requisies HTTP feitas ao servidor,
mesmo que estes dados no sejam necessrios. Isso significa que um mesmo
conjunto de dados so retransmitidos sempre ao servidor, consumindo recursos
de rede e processamentos desnecessrios, que acabam ocasionando atrasos
2

tanto na comunicao quanto na execuo das aplicaes web que precisam

tratar esses dados, toda vez que eles so reenviados;
iv) a menos que toda a aplicao web esteja servida sobre o protocolo de
segurana SSL (Secure Socket Layer), a transmisso dos cookies feita atravs
da rede internet normalmente sem nenhum tipo de criptografia;
v) os cookies no funcionam bem quando diferentes transaes so executadas de
um mesmo site, usando mais de uma janela/aba. Por exemplo, se um usurio
estiver comprando uma passagem area de um mesmo site usando duas
janelas/abas diferentes e se este site estiver usando cookies para fazer o
rastreamento de qual nmero de passagem o usurio est comprando, pode
ocorrer que, se o usurio mudar de janela, o nmero da passagem de uma
janela "vaze" para a outra, podendo fazer com que o usurio acabe comprando
duas passagens para um mesmo voo, quando na verdade ele s queria comprar
apenas uma passagem (WHATWG, 2013). Portanto, em certas situaes, pode
ocorrer que os dados armazenados nos cookies de uma transao em uma das
janelas, causem interferncias nos dados dos cookies de uma outra transao
aberta em uma outra janela para um mesmo site.
Na busca de uma soluo para alguns desses problemas, algumas tcnicas usando
plugins2 chegaram a ser desenvolvidas e utilizadas em alguns sites. No entanto, apesar de
resolverem algumas das questes dos cookies, as solues usando esses recursos, porm,
apresentavam outras limitaes e desvantagens (PILGRIM, 2011):
i)

eram dependentes de um nico navegador;

ii) em sua maioria, necessitam da instalao de plugins de terceiros;

iii) no possuam um padro de interface comum (ou API - Application
Programming Interface) (CIRIACO, 2009);
iv) tinham diferentes limitaes de armazenamento;
v) apresentavam diferentes experincias de usabilidade; etc.

plugin: pequeno programa que no pode ser executado de forma independente e que funciona como um
mdulo de extenso, adicionando funcionalidades novas ou especficas a outros programas maiores.

Esse cenrio permaneceu por um bom perodo e s comeou a mudar a partir dos
ltimos anos com a exploso dos dispositivos mbiles e com o surgimento de uma nova
modalidade de software: os aplicativos nativos3.
Dessa nova onda surgiram tambm outras modalidades de softwares: aquelas
baseadas em aplicativos web, que basicamente fazem uso de recursos open-sources
(HTML, CSS, Javascript, etc.), e as hbridas, onde as duas tecnologias (nativo+web) se
misturam.
No cabe aqui fazermos uma avaliao dessas tecnologias. Atualmente, existe uma
grande discusso a respeito dos prs/contras, vantagens/desvantagens de cada uma delas e
essa discusso parece estar apenas comeando (JONES, 2012; MITRA , 2013; WHITNEY,
2012). No entanto, cabe aqui destacar que uma das principais vantagens das aplicaes
nativas sobre as aplicaes web o uso de armazenamento local que feito atravs do
sistema operacional do prprio equipamento do usurio, permitindo que os aplicativos
mantenham localmente os seus principais dados (preferncias do usurio, estado do
aplicativo em tempo de execuo, armazenamento e registro de informaes, etc.).

Web storage
Para cobrir a falta de uma soluo padro que substitusse os cookies e os plugins
no armazenamento local de dados das aplicaes web, junto com a especificao do
HTML5 (WHATWG, 2013; W3C, 2013), surge o Web storage, uma interface de
programao de aplicativos padronizada (ou API), implementado de forma nativa nos
navegadores web, sem a necessidade da instalao de plugins.

Programas construdos usando-se uma linguagem de programao especfica para um dado dispositivo tais
com, por exemplo: Objective-C usado no IOS, Java no Android, etc.

O funcionamento do Web storage, a princpio, bastante similar ao do cookie. Os

dados salvos localmente pelo navegador so organizados em pares do tipo chave/valor,
onde um certo valor associado uma dada chave, tal como podemos observar nos
seguintes exemplos abaixo:

chave: nome, valor: Fulano de Tal

chave: email, valor: fdetal@sicrano.com.br

chave: empresa, valor: Sicrano S.A

As semelhanas entre esses dois recursos, no entanto, param por a.

i)

ao contrrio dos cookies, os dados armazenados localmente via Web storage

esto disponveis apenas para a mquina cliente e no so enviados
automaticamente ao servidor web nas comunicaes cliente-servidor. Se quiser
tornar esses dados disponveis ao servidor, preciso envi-los usando algum
recurso de programao na mquina cliente (p.ex. Javascript);

ii) o padro Web storage define um limite de armazenamento de no mximo

5MB4 de dados por origem5. Uma quantidade bem maior que os 4KB dos
cookies;
iii) os dados das transaes para um mesmo site que estejam em janela/abas
diferentes podem ser protegidas ou compartilhadas com outras janelas. No
entanto, cabe ao desenvolvedor escolher qual modalidade ir usar, conforme as
especificaes do sistema web que ele estiver desenvolvendo;
iv) para aplicaes web offline, o Web storage um recurso indispensvel, uma
vez que ao fornecer um tratamento para o armazenamento local de dados, ele
permite que o usurio continue trabalhando com o aplicativo sem precisar estar
conectado a uma rede Internet; etc.
4

O limite de 5MB um valor sugerido pela especificao HTML5. No entanto, alguns os navegadores
podem adotar valores diferentes desse limite (maiores ou menores). Em certos navegadores possvel at
configurarmos a quantidade que desejamos alocar para o Web storage. No endereo http://devtest.nemikor.com/web-storage/support-test/ fornecido uma tabela com os valores adotados por algumas
plataformas, sendo possvel inclusive executarmos um teste local que verificar qual a capacidade de
armazenamento no Web storage do seu navegador.
5

O conceito de origem um termo definido no documento RFC6454: "The web origin concept"
(http://tools.ietf.org/html/rfc6454).

Modos de armazenamento no Web storage

O padro Web storage oferece dois tipos de armazenamento de dados: Session
storage e Local storage. Ambos os tipos implementam e disponibilizam uma mesma
interface de programao API.
O modo de armazenamento Session storage permite-nos o acesso aos dados
especficos de uma janela/aba, isolando as informaes das outras janelas/abas (modo
protegido). Mesmo que o usurio esteja visitando um mesmo site (origem), usando duas
janelas em um mesmo navegador, cada janela/aba ter os dados de sua sesso armazenados
de forma individual e separada uma das outras.
Os dados armazenados no Session storage so do tipo no persistentes, o que
significa que os dados armazenados nesse modo esto disponveis apenas enquanto a
sesso durar. Ou seja, os dados existem (persistem) enquanto a janela/aba que estiver
visitando o site, estiver aberta. Quando fecharmos a janela/aba do navegador, os dados
armazenados no Session storage so apagados permanentemente.
O modo de armazenamento Local storage, por outro lado, permite-nos o
armazenamento de dados de modo persistente. Assim, nesse modo, os dados salvos
permanecem guardados mesmo que fechemos a janela/aba do navegador. Dessa forma,
quando o usurio visitar o site uma outra vez, os dados salvos no Local storage podem ser
recuperados e disponibilizados ao usurio novamente.
Uma outra caracterstica interessante do Local storage que os dados armazenados
nesse modo no possuem limitaes de acesso, isso permite que os dados de uma janela/
aba de um navegador possam ser acessados por outra que esteja acessando a mesma
origem (modo compartilhado).
Para algumas aplicaes web, essas caractersticas podem ser imprescindveis. Por
exemplo, suponha que um usurio esteja comparando dois produtos diferentes de um
mesmo site, usando duas abas diferentes. Aps escolher em uma das abas qual produto ir
colocar no carrinho de compras, se os dados da compra nesse site forem armazenados no
Local storage, automaticamente, eles estaro disponveis para a outra aba aberta ou para
aquelas, que forem abertas futuramente para esse mesmo site. Alm do mais, se o usurio
6

precisar fechar as abas do navegador, ele poder finalizar as compras mais tarde, pois os
dados do carrinho de compras armazenados no Local storage estaro disponveis para
quando o usurio voltar a visitar o site novamente.

Storage API
A Storage API uma interface padronizada que fornece os mtodos de acesso a
lista de pares chave/valor (itens) armazenados no Web storage. Esse acesso feito atravs
de dois objetos Storage API: sessionStorage e localStorage, associados a cada um
dos tipos de armazenamento. Assim, se quisermos acessar os dados armazenados na
Session storage, usamos o objeto sessionStorage e, para os dados no Local storage,
usamos localStorage.
A interface Storage disponibiliza os seguintes recursos:
length - atributo que retorna o nmero de itens que esto armazenados no objeto
Storage.
// Informa a quantidade de itens armazenados no objeto localStorage
alert(localStorage.length);

key(n) - mtodo que retorna a chave do n-ensimo item armazenado.

// Mostra as chaves dos itens armazenadas no localStorage
for(i=0; i<localStorage.length; i++) {
alert(localStorage.key(i));
}

setItem(key, value) - mtodo que insere um novo item key/value lista de

armazenamento do objeto storage.
getItem(key) - mtodo que retorna o valor do item associado a chave especificada
em key.
removeItem(key) - mtodo que remove um item da lista, cuja chave key.
clear() - mtodo que remove todos os itens armazenados em um objeto Storage.

Verificando o suporte ao Web storage no navegador

Assim como muitos dos novos recursos inseridos no HTML5, o Web storage no
exceo, pode ocorrer dele no ser suportado por um navegador. Atualmente, esse recurso
suportado pelas seguintes verses de navegadores6:

Internet Explorer 8+

Opera 10.5+

Firefox 3.5+

iOS Safari 10.5+

Chrome 4+

Navegador Android 2.1+

Safari 4+

Para verificarmos se o navegador possui suporte ao Web storage, preciso usar

uma funo em Javascript para checar a existncia dos objetos de armazenamento que
precisar ou for usar: localStorage e/ou o sessionStorage.
No cdigo abaixo dado uma funo que testa o suporte ao Local storage. Uma
funo semelhante pode ser criada para verificar a existncia de suporte ao Session
storage.
function localStorage_is_supported() {
try {
return "localStorage" in window && window["localStorage"] !== null;
} catch(e) {
return false;
}
}

Assim, se quisermos verificar a existncia (ou no) do suporte ao Local storage,

devemos executar o seguinte teste:
if (localStorage_is_supported()) {
// Rotina de tratamento para quando o modo de armazenamento
// Local storage suportado pelo navegador
}else{
// Rotina para quando o Local storage NO suportado
}

Fonte: http://caniuse.com/#search=web storage. Acesso em: 24/10/2013.

Se preferir, uma alternativa para a soluo acima empregar a biblioteca Javascript

Modernizr7, fazendo o seguinte teste:
<script src="modernizr-latest.js"></script>
...
if (Modernizr.localStorage) {
// Local storage suportado pelo navegador
}else{
// Local storage NO suportado pelo navegador
}

Armazenando dados do Web storage

O armazenamento no Web storage feito atravs de uma chamada ao mtodo
setItem(key, value), aplicado sobre o objeto Storage no qual queremos armazenar o

dado (Exemplo-1).
Exemplo-1: Uso do mtodo setItem() para armazenar dados locais no Web storage.
localStorage.setItem("nome", "Fulano de Tal Filho");
sessionStorage.setItem("dolar", 2.31);
localStorage.setItem("assegurado", true);
localStorage.setItem("contagem", 5);

Na chamada do mtodo, o argumento key deve ser um valor do tipo string,

enquanto que value pode variar o seu tipo, pois o valor informado em value convertido
automaticamente para o tipo string antes dele ser armazenado no objeto Storage.
Uma restrio ao uso da API que a funo setItem() no tem como armazenar
o "valor" diretamente, caso este seja um objeto. Para esses casos, a soluo adotada
armazenar o objeto como uma string JSON8, usando uma funo nativa do Javascript
JSON.stringify(Objeto). Esse processo de converso de objeto em string

conhecido como serializao9. Vejamos abaixo um exemplo de uso dessa funo.

http://modernizr.com/downloads/modernizr-latest.js

http://pt.wikipedia.org/wiki/JSON

http://pt.wikipedia.org/wiki/Serializao

Exemplo-2: Serializao de objetos para armazenamento no Web storage.

// Momento em uma instncia de uma classe qualquer criada
var obj = new Uma_Classe_Qualquer();
...
// Serializao desse objeto para o formato string JSON,
// de modo que possamos salv-lo em localStorage.
localStorage.setItem("objeto", JSON.stringify(obj));

Um outro aspecto importante do funcionamento do mtodo que ele checa a

existncia da chave key na lista de itens. Se essa chave no existir, um novo item usando o
par key/value criado e adicionado lista. Porm, se essa a chave existir, o valor do item
s ser modificado se value for um valor diferente do valor correntemente armazenado no
item.
Para o caso em que o mtodo no consiga criar um novo item, ou no consiga
modific-lo, uma exceo QUOTA_EXCEEDE_ERR disparada, indicando que a cota de
armazenamento de dados locais excedeu. Essa exceo pode, ento, ser capturada e tratada
usando simplesmente uma estrutura try/catch.
Exemplo-3: Tratamento de erros de armazenamento no Web storage.
try {
localStorage.setItem("chave", valor);
} catch(e) {
if (e==QUOTA_EXCEEDE_ERR) {
alert("Excedeu cota de armazenamento!");
}else{
alert("Seu navegador no tem suporte para o localStotage!");
}
}

Recuperando dados do Web storage

A recuperao de dados do Web storage feita usando-se o mtodo

getItem(key) aplicado sobre um dos objetos de armazenamento. Assim, tomando-se o

Exemplo-1, para recuperarmos os dados armazenados no Web storage faramos:

10

Exemplo-4: Recuperando dados do Web storage.

var
var
var
var

str = localStorage.getItem("nome"); // str = "Fulano..."

cotacao = sessionStorage.getItem("dolar"); // cotacao="2.31"
temSeguro = localStorage.getItem("assegurado"); // temSeguro="true"
cont = localStorage.getItem("contagem"); // cont="5"

Para os casos em que a chave informada no getItem(key) no exista na lista de

itens armazenados no objeto storage, o mtodo retorna um valor null.
var v = localStorage.getItem("xxx"); // v = null

Convertendo os dados recuperados do Web storage

Nos comentrios do exemplo anterior (Exemplo-4), pode-se observar que os dados
retornados pelo mtodo getItem() so todos eles do tipo string . Isso ocorre em razo
dos valores serem convertidos para o formato string, quando so armazenados no objeto
Storage.
Dessa forma, dependendo da programao, pode ser necessrio que tenhamos que
converter esses dados para o tipo apropriado varivel que os receber. Podemos fazer
isso, usando uma funo de converso de tipos do Javascript tal como o parseInt() ou o
parseFloat(), por exemplo, ou algum outro recurso de programao.

Exemplo-5: Converso de dados do Web storage.

var str = localStorage.getItem("nome");
// Para esse caso, no necessrio converso
// str = "Fulano..."
var cotacao = parseFloat(sessionStorage.getItem("dolar"));
// Converso para o tipo numrico em ponto-flutuante
// cotacao=2.31
var temSeguro = (localStorage.getItem("assegurado")=='true');
// Converso para o tipo booleano
// temSeguro=true
var cont = parseInt(localStorage.getItem("contagem"));
// Converso para o tipo inteiro
// cont=5

11

var obj = JSON.parse(localStorage.getItem("objeto"));

// Converso para um objeto (desserializao)

Excluindo dados do Web storage

Quando os dados armazenados no Web storage no so mais necessrios ou
precisarem

ser removidos, podemos

exclu-los fazendo

chamadas ao mtodo

removeItem(key), informando a chave do dado que queremos excluir.

Exemplo-6: Removendo individualmente dados do Web storage.

localStorage.removeItem("nome"); // Remove o item nome do Local storage
sessionStorage.removeItem("dolar"); // Remove dolar de Session storage

Caso a chave informada no exista na lista de itens do objeto storage, o mtodo no

faz absolutamente nada.
localStorage.removeItem("xxx"); // No faz nada!

Entretanto, aA remoo de todas as chaves do objeto Storage, uma a uma, pode ser
uma tarefa entediante e sujeita a erros. Para esses casos, quando quisermos remover todos
os dados, fazemos uma nica chamada ao mtodo clear(), que ir apagar de uma s vez
todos os dados armazenados no objeto Storage.
Exemplo-7: Excluindo todos os dados armazenados em um objeto Storage.
// Remove todos os itens armazenados em Local storage
localStorage.clear();

Controlando as alteraes dos dados no Web Storage - Evento storage

Vamos supor o caso em que um usurio tenha vrias instncias (janelas/abas) de
um mesmo site aberto em um dado momento e que tenha feito mudanas na rea de
armazenamento de uma delas, que precisam ser aplicadas nas outras instncias de modo a
sincroniz-las.
12

Esse controle e sincronizao de dados pode ser feito atravs da captura do evento
storage, que disparado automaticamente em todas as instncias que tem acesso aos dados
inseridos, modificados ou apagados10. Esse disparo ocorre, toda vez que algum dos
mtodos: setItem(), removeItem() ou clear() invocado em uma das janelas/abas de
modo que as outras instncias sejam informadas que houve uma modificao na lista de
itens armazenados no Web storage.
Assim, se quisermos manter o controle das mudanas no armazenamento,
precisamos capturar o evento storage atravs de uma funo (callback) que ir trat-lo.
A captura do evento storage feita checando-se primeiro qual o mecanismo de
tratamento de eventos o navegador suporta: addEventListener
window.attachEvent

11

(padro HTML5) ou

(padro adotado no Internet Explorer <IE9)

Exemplo-8: Tratamento e captura do evento storage.

if (window.addEventListener) {
// Padro HTML5
window.addEventListener('storage', storageEventHandler, false);
}else{
// Padro IE
window.attachEvent("onstorage", storageEventHandler);
}
...
// Rotina para tratamento do evento storage
function storageEventHandler(event) { ... }

Segurana no Web storage

Um ponto importante que tambm deve ser salientado aqui que, quando se est
trabalhando com Web storage, os dados armazenados em um navegador so especficos
dele. Assim, se estiver visitando um site usando o Chrome e visitar esse mesmo site com o

10

Na maioria dos navegadores, o disparo do evento Storage s ocorre nas outras janela/abas, no ocorrendo
na janela/aba onde os dados foram modificados. Entretanto, no Internet Explorer, o disparo desse evento
ocorre em todas as janelas/abas, inclusive naquela em que os dados foram modificados.
11

O padro W3C addEventListener s foi adicionado ao Internet Explorer a partir do IE9.

13

Firefox, por exemplo, os dados salvos em um navegador no estaro disponveis para o

outro e vice-versa.
Alm disso, a segurana do Web storage conhecida como segurana baseada na
origem (origem-based security). Isso significa que os dados armazenados no Web storage
para um dado domnio so acessveis somente para as pginas desse domnio, fazendo com
que o acesso aos dados locais de domnios diferentes sejam inacessveis, tanto para leitura
quanto para escrita.
Um outro aspecto importante que os dados armazenados no Web storage no so
transmitidos nas requisies feitas ao servidor, assim como os cookies, a menos que o
desenvolvedor queira/precise envi-los. Nesses casos, usa-se Javascript para transmit-lo e
uma camada extra de segurana pode ser implementada, criptografando-se os dados antes
de envi-los ao servidor, usando o protocolo HTTPS (HTTP seguro).
Nos casos em que a segurana dos dados for crtica, caber ao desenvolvedor
implementar as rotinas que garantam nveis de segurana mais elevados, juntamente com a
adoo de certos protocolos de segurana (JONES, 2013).

Exemplos de uso do Web storage

http://www.diveintojavascript.com/tutorials/web-storage-tutorial-creating-anaddress-book-application - Tutorial JavaScript Web Storage para a criao de

uma aplicao de caderno de endereos.

http://html5demos.com/storage - Teste de armazenamento no Web storage.

http://html5demos.com/storage-events - Teste para o evento Storage.

http://www.cjihrig.com/development/html5/storage.htm - Um exemplo simples

de uso do Web Storage.

http://webdesignandseo.net/scripts/localstorage/ - Pgina que implementa uma

rotina em cookie que substitui o localStorage, caso o navegador no tenha
suporte ao Web Storage.

http://www.ellipsetours.com/Demos/storage/ - Demonstrao do API storage,

com um toque de JQuery UI.
14

Concluso
Alm dos aplicativos web, muitos sites esto se beneficiando do Web storage e
esto comeando a disponibilizar novos servios e adicionando novas funcionalidades s
pginas, abrindo novas oportunidades de negcios.
Dentre as partes fortes do Web storage, destacam-se:

uma API fcil de usar.

Disponibiliza dois modos de armazenamentos: persistente (local storage) e

no-persistente (session storage).

Possui um evento (storage event) que ajuda a manter os dados das janelas/abas
sincronizadas.

possui amplo suporte em equipamentos e dispositivos variados (computador,

tablets, celulares, etc.), mais o suporte em software (incluindo a o IE8+).

Seus pontos fracos so:

As informaes gravadas no Web storage so armazenadas no formato string,

no no formato original do dado. Se estiver armazenando valores inteiros ou
nmeros em formato ponto-flutuante (float), por exemplo, a converso desses
valores em strings pode resultar em um consumo maior de memria, pois cada
dgito do nmero estar sendo armazenado como um caracter. Alm disso,
gasta-se um tempo de processamento nas converses dos dados de/para o Web
storage.

O Web storage ainda no possui nenhum mecanismo para que os

desenvolvedores requisitem mais espao de armazenamento de modo a
aumentar a cota de 5Mb.

O Web storage no oferece nenhum recurso de transao, indexao e busca.

O Web storage uma tecnologia recente que ainda est amadurecendo, portanto,
sujeita a novas atualizaes que venham acrescentar-lhe outras funcionalidades (p.ex.
criptografia, armazenamento de tipo diferente de string, recursos para modificao de
cotas, etc.).
15

Alm do Web storage, existem outras tecnologias que podem ser usadas para se
fazer o armazenamento de dados locais: variveis Javascript, window.name, Web SQL,
IndexeDB, HTML5 File API, etc. No artigo de Backler (2013), encontramos um pequeno
resumo sobre alguns deles.

Referncias
BACKLER, Craig. HTML5 Browser storage: the past, present and future. Sitepoint.
09/10/2013. Disp. em: http://www.sitepoint.com/html5-browser-storage-past-presentfuture. Acesso em: 28/10/2013.
CIRIACO, Douglas. O que API? Tecmundo. 24/03/2009. Disp. em:
http://www.tecmundo.com.br/programacao/1807-o-que-e-api-.htm#ixzz2Ol1zcuRU.
Acesso em: 27/08/2013.
GOLDSTEIN, Alexis; LAZARIS, Louis; WEYL, Estelle. HTML5 and CSS3 for the real
world. Sitepoint. 2011.
IHRIG, Colin. An overview of the web storage API. Sitepoint. 2012. Disp. em:
www.sitepoint.com/an-overview-of-the-web-storage-api/. Acesso em: 13/09/2013.
JONES, Adrian. Native, Hybrid or Web apps. Sitepoint. 09/01/2012. Disp. em:
http://www.sitepoint.com/native-hybrid-or-web-apps/. Acesso em: 29/08/2013.
JONES, Zach. Web Storage Security. White Hat Security. 28/03/2013.
Disp. em: https://blog.whitehatsec.com/web-storage-security/. Acesso em: 23/10/2013.
MITRA, Tilo. Developing a web app vs. a native app. 09/05/2013.
Disp. em: http://tilomitra.com/web-vs-native/. Acesso em: 29/08/2013.
NASCIMENTO, Jean. Utilizando a Storage API do HTML5. iMasters. 11/04/2011.
Disp. em: http://imasters.com.br/artigo/20315/desenvolvimento/utilizando-a-storage-apido-html5/. Acesso em: 26/08/2013.
PILGRIM, Mark. Dive into HTML5. 2011. (verso em portugus). Disp. em:
http://diveintohtml5.com.br/storage.html#methods. Acesso em: 26/08/2013.
SRINIVASAN, Rathnakanya K. HTML5 Web Storage. Sitepoint. 08/08/2013.
Disp. em: http://www.sitepoint.com/html5-web-storage/. Acesso em: 26/08/2013.

16

W3C. Web Storage: Recommendation 30 July 2013.

Disp. em: http://www.w3.org/TR/2013/REC-webstorage-20130730/.
Acesso em: 30/08/2013.
WHATWG. Web Storage. Disp. em: http://www.whatwg.org/specs/web-apps/currentwork/multipage/webstorage.html. Acesso em: 26/08/2013.
WHITNEY, Lee. Offline capabilities: Native mobile apps vs. Mobile web apps. Sitepoint.
04/05/2012. Disp. em: http://www.sitepoint.com/offline-capabilities-native-mobile-appsvs-mobile-web-apps/. Acesso em: 29/08/2013.
W3SCHOOLS. JavaScript Tutorial. Disp. em: http://www.w3schools.com/js/.
Acesso em: 28/10/2013.

17