Servicio web

Ir a la navegaciónIr a la búsqueda
Un servicio web (en inglés, web service o web services) es una tecnología que
utiliza un conjunto de protocolos y estándares que sirven para intercambiar datos
entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes
de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden
utilizar los servicios web para intercambiar datos en redes de
ordenadores como Internet. La interoperabilidad se consigue mediante la adopción
de estándares abiertos. Las organizaciones OASIS y W3C son los comités
responsables de la arquitectura y reglamentación de los servicios Web.
El W3C define un servicio web como:
Un servicio web es un sistema software diseñado para soportar la interacción máquina-a-máquina, a
través de una red, de forma interoperable. Cuenta con una interfaz descrita en un formato procesable
por un equipo informático (específicamente en WSDL), a través de la que es posible interactuar con el
mismo mediante el intercambio de mensajes SOAP, típicamente transmitidos usando
serialización XML sobre HTTP conjuntamente con otros estándares web.
W3C1

Para mejorar la interoperabilidad entre distintas implementaciones de servicios

Web se ha creado el organismo WS-I, encargado de desarrollar diversos perfiles
para definir de manera más exhaustiva estos estándares. Es una máquina que
atiende las peticiones de los clientes web y les envía los recursos solicitados.

Índice

 1Arquitectura
 2Estándares empleados
 3Ventajas de los servicios web
 4Inconvenientes de los servicios web
 5Razones para crear servicios Web
 6Plataformas
 7Véase también
 8Referencias
 9Enlaces externos

Arquitectura[editar]
Arquitectura de los Servicios Web SOAP

En la arquitectura de servicios web existen tres partes: proveedor de servicios

web, el que pide el servicio web y el publicador. El proveedor de servicios envía al
publicador del servicio un fichero WSDL con la definición del servicio web. El que
pide el servicio contacta con el publicador y descubre quién es el proveedor
(protocolo WSDL) y contacta con el proveedor (protocolo SOAP). El proveedor
valida la petición de servicio y envía el dato estructurado en formato XML
utilizando el protocolo SOAP. El fichero XML es validado de nuevo por el que pide
el servicio utilizando un fichero XSD.

Estándares empleados[editar]
 Web Services Protocol Stack: conjunto de servicios y protocolos de los
servicios web.
 XML (Extensible Markup Language): formato estándar para los datos que
se vayan a intercambiar.
 SOAP (Simple Object Access Protocol) o XML-RPC (XML Remote
Procedure Call): protocolos sobre los que se establece el intercambio.
 Otros protocolos: los datos en XML también pueden enviarse de una
aplicación a otra mediante protocolos normales como Hypertext Transfer
Protocol (HTTP), File Transfer Protocol (FTP), o Simple Mail Transfer
Protocol (SMTP).
 WSDL (Web Services Description Language): es el lenguaje de la interfaz
pública para los servicios web. Es una descripción basada en XML de los
requisitos funcionales necesarios para establecer una comunicación con los
servicios web.
 UDDI (Universal Description, Discovery and Integration): protocolo para
publicar la información de los servicios web. Permite comprobar qué servicios
web están disponibles.
 WS-Security (Web Service Security): protocolo de seguridad aceptado
como estándar por OASIS (Organization for the Advancement of Structured
Information Standards). Garantiza la autenticación de los actores y la
confidencialidad de los mensajes enviados.
 REST (Representational State Transfer): arquitectura que, haciendo uso del
protocolo HTTP, proporciona una API que utiliza cada uno de sus métodos
(GET, POST, PUT, DELETE, etcétera) para poder realizar diferentes
operaciones entre la aplicación que ofrece el servicio web y el cliente.
 GraphQL, arquitectura alternativa a REST.

Ventajas de los servicios web[editar]

 Aportan interoperabilidad entre aplicaciones de software
independientemente de sus propiedades o de las plataformas sobre las que se
instalen.
 Los servicios Web fomentan los estándares y protocolos basados en texto,
que hacen más fácil acceder a su contenido y entender su funcionamiento.
 Permiten que servicios y software de diferentes compañías ubicadas en
diferentes lugares geográficos puedan ser combinados fácilmente para proveer
servicios integrados.

Inconvenientes de los servicios web[editar]

 Para realizar transacciones, no pueden compararse en su grado de
desarrollo con los estándares abiertos de computación
distribuida como CORBA (Common Object Request Broker Architecture).
 Su rendimiento es bajo si se compara con otros modelos de computación
distribuida, tales como Java Remote Method
Invocation (RMI), CORBA o Distributed Component Object Model (DCOM). Es
uno de los inconvenientes derivados de adoptar un formato basado en texto. Y
es que entre los objetivos de XML no se encuentra la concisión ni la eficacia de
procesamiento.
 Al apoyarse en HTTP, pueden esquivar medidas de seguridad basadas
en firewall cuyas reglas tratan de bloquear o auditar la comunicación entre
programas a ambos lados de la barrera.

Razones para crear servicios Web[editar]

La principal razón para usar servicios Web es que se pueden utilizar con HTTP
sobre Transmission Control Protocol (TCP) en el puerto de red 80. Dado que las
organizaciones protegen sus redes mediante firewalls (que filtran y bloquean gran
parte del tráfico de Internet), cierran casi todos los puertos TCP salvo el 80, que
es, precisamente, el que usan los navegadores web. Los servicios Web utilizan
este puerto, por la simple razón de que no resultan bloqueados. Es importante
señalar que los servicios web se pueden utilizar sobre cualquier protocolo, sin
embargo, TCP es el más común.
Otra razón es que, antes de que existiera SOAP, no había buenas interfaces para
acceder a las funcionalidades de otras computadoras en red. Las que había
eran ad hoc y poco conocidas, tales como Electronic Data
Interchange (EDI), Remote Procedure Call (RPC), u otras API.
Una tercera razón por la que los servicios Web son muy prácticos es que pueden
aportar gran independencia entre la aplicación que usa el servicio Web y el propio
servicio. De esta forma, los cambios a lo largo del tiempo en uno no deben afectar
al otro. Esta flexibilidad será cada vez más importante, dado que la tendencia a
construir grandes aplicaciones a partir de componentes distribuidos más pequeños
es cada día más utilizada.
Se espera que para los próximos años mejoren la calidad y cantidad de servicios
ofrecidos basados en los nuevos estándares.

Plataformas[editar]
Servidores de aplicaciones para servicios Web:

 JBoss servidor de aplicaciones J2EE Open Source de Red Hat inc.

 Oracle Fusion Middleware
 IBM Lotus Domino a partir de la versión 7.0
 Axis y el servidor Jakarta Tomcat (de Apache)
 ColdFusion MX de Macromedia
 Java Web Services Development Pack (JWSDP) de Sun
Microsystems (basado en Jakarta Tomcat)
 JOnAS (parte de ObjectWeb una iniciativa de código abierto)
 Microsoft .NET
 Novell exteNd (basado en la plataforma J2EE)
 WebLogic
 WebSphere
 JAX-WS con GlassFish
 Zope es un servidor de aplicaciones Web orientado a objetos desarrollado
en el lenguaje de programación Python
 VERASTREAM de AttachmateWRQ para modernizar o integrar
aplicaciones host IBM y VT
Simple Object Access Protocol
Ir a la navegaciónIr a la búsqueda

Estructura de un mensaje SOAP

SOAP (originalmente las siglas de Simple Object Access Protocol) es

un protocolo estándar que define cómo dos objetos en diferentes procesos pueden
comunicarse por medio de intercambio de datos XML. Este protocolo deriva de un
protocolo creado por Dave Winer en 1998, llamado XML-RPC. SOAP fue creado
por Microsoft, IBM y otros. Está actualmente bajo el auspicio de la W3C. Es uno
de los protocolos utilizados en los servicios Web.

Características[editar]
SOAP es un paradigma de mensajería de una dirección sin estado, que puede
ser utilizado para formar protocolos más completos y complejos según las
necesidades de las aplicaciones que lo implementan. Puede formar y construir la
capa base de una "pila de protocolos de web service", ofreciendo un framework de
mensajería básica en el cual los web services se pueden construir. Este protocolo
está basado en XML y se conforma de tres partes:

 Sobre (envelope): el cual define qué hay en el mensaje y cómo procesarlo.

 Conjunto de reglas de codificación para expresar instancias de tipos de datos.
 La Convención para representar llamadas a procedimientos y respuestas.
El protocolo SOAP tiene tres características principales:

 Extensibilidad (seguridad y WS-routing son extensiones aplicadas en el

desarrollo).
 Neutralidad (bajo protocolo de transporte TCP puede ser utilizado sobre cualquier
protocolo de aplicación como HTTP, SMTP o JMS).
 Independencia (permite cualquier modelo de programación).
Como ejemplo de cómo el modelo SOAP pueda ser utilizado, consideraremos un
mensaje SOAP que podría ser enviado a un web service para realizar la búsqueda
de algún precio en una base de datos, indicando para ello los parámetros
necesitados en la consulta. El servicio podría retornar un documento en formato
XML con el resultado, un ejemplo, precios, localización o características. Teniendo
los datos de respuesta en un formato estandarizado procesable (en inglés
"parsable"), éste puede ser integrado directamente en un sitio Web o aplicación
externa.
La arquitectura SOAP está formada por varias capas de
especificación: MEP (Message Exchange Patterns) para el formato del mensaje,
enlaces subyacentes del protocolo de transporte, el modelo de procesamiento de
mensajes, y la capa de extensibilidad del protocolo. SOAP es el sucesor de XML-
RPC, a pesar de que toma el transporte y la neutralidad de la interacción, así
como el envelope / header / body, de otros modelos (probablemente de WDDX).

Estructura del mensaje[editar]

Un mensaje SOAP es un documento XML ordinario con una estructura definida en
la especificación del protocolo. Dicha estructura la conforman las siguientes
partes:

 Envelope (obligatoria): raíz que de la estructura, es la parte que identifica al

mensaje SOAP como tal.
 Header: esta parte es un mecanismo de extensión ya que permite enviar
información relativa a cómo debe ser procesado el mensaje. Es una herramienta para
que los mensajes puedan ser enviados de la forma más conveniente para las
aplicaciones. El elemento "Header" se compone a su vez de "Header Blocks" que
delimitan las unidades de información necesarias para el header.
 Body (obligatoria): contiene la información relativa a la llamada y la respuesta.
 Fault: bloque que contiene información relativa a errores que se hayan producido
durante el procesado del mensaje y el envío desde el "SOAP Sender" hasta el
"Ultimate SOAP Receiver".
En los próximos apartados de este documento se podrá apreciar esta estructura
con ejemplos concretos.

Modelo de procesado[editar]
El modelo de procesado de SOAP está definido como un sistema distribuido, en el
que intervienen diferentes nodos. En un escenario básico, los nodos SOAP se
comunican uno asumiendo el rol de SOAP Sender y otro el de SOAP Receiver.
Aun así, la especificación define diferentes tipos de nodos en función del rol que
asumen en el envío del mensaje:

 SOAP Sender: nodo que transmite un mensaje SOAP.

 SOAP Receiver: nodo que acepta un mensaje.
 SOAP message path: conjunto de nodos por los cuales debe pasar un mensaje
SOAP, incluyendo el nodo inicial, cero o más nodos intermediarios y el SOAP
Receiver definitivo.
 Initial SOAP sender: el "sender" que origina el mensaje y que es el punto de inicio
del camino que seguirá el mensaje.
 SOAP intermediary: el intermediario actúa como SOAP receiver y como SOAP
sender, ya que primero recibe el mensaje para después reenviarlo al siguiente nodo
en el camino.
 Ultimate SOAP receiver: destino final del mensaje SOAP, es el responsable de
procesarlo. Cabe destacar que el mensaje podría no llegar al receptor definitivo
debido a que problemas en los intermediarios hagan que se pierda.
Un nodo SOAP puede actuar con uno o varios roles, cada uno de los cuales se
encuentra definido mediante una URI conocida como el nombre de rol. Los roles
asumidos por un nodo son invariantes durante el envío de un mensaje, teniendo
en cuenta la especificación el procesado individual de mensajes. Tal y como se ha
comentado, una aplicación puede crear protocolos de comunicación más
complejos como capas superiores sobre SOAP, pudiendo definir sus propios roles
para poder cumplir con sus necesidades.
La especificación de SOAP define unas normas sobre cómo deben ser
procesados, definiendo una serie de pasos que deben cumplir las
implementaciones del protocolo. Estos pasos se pueden encontrar en la
sección 2.6 de la especificación de W3C.

Ventajas y desventajas[editar]
Ventajas[editar]

 Debido al uso de XML permite invocar procedimientos remotos de muchos

lenguajes, por lo tanto, presenta una gran interoperabilidad.
 Al utilizar una comunicación vía HTTP es fácilmente escalable, además de ser casi
siempre permitido por los cortafuegos.
 Puede ser implementado utilizando cualquier lenguaje y ejecutado en cualquier
plataforma.
 Es posible utilizarlo mediante usuario anónimo y mediante autentificación.
 Es posible transmitirlo mediante cualquier protocolo de transporte capaz de
transmitir texto, típicamente HTTP o SMTP.
Desventajas[editar]

 Debido al uso de XML para el paso de mensajes, SOAP es considerablemente

más lento que otros middleware como CORBA ya que los datos binarios se
codifican como texto. Para contrarrestar este punto débil en el caso de XML con
código binario incrustado se desarrolló un método optimizado de transmisión de
mensajes.
 Depende del WSDL (Web Services Description Language).
 Al contrario que Java, PHP o Python ciertos lenguajes no ofrecen un apoyo
adecuado para su uso ya sea a nivel de integración o de soporte IDE.
Casos de uso[editar]
La forma más habitual de utilizar el protocolo SOAP es mediante el
patrón petición-respuesta con remitente SOAP y destinatario final SOAP, el
cual es utilizado cuando los mensajes SOAP están predefinidos y únicamente
se desea enviar una petición y consultar su valor de retorno.
No obstante, muchas veces este patrón no es suficiente, y es necesario
establecer un intercambio múltiple de mensajes entre los nodos. La W3C
define dos tipos de intercambios de mensajes SOAP para formar una
conversación:

 Intercambio de mensajes Conversacionales: permite redefinir la información de

la petición. Estos intercambios pueden acabar comportándose como un patrón de
mensajes de ida y vuelta.

 Llamadas a Procedimientos Remotos: permite encapsular la funcionalidad de

procedimientos remotos utilizando las ventajas de XML de extensibilidad y
funcionalidad, por este motivo se ha definido en la especificación una
representación uniforme para realizar invocaciones y respuestas RPC mediante
mensajes SOAP.
En ocasiones, es necesario el uso de intermediarios en las comunicaciones
SOAP, la especificación SOAP 1.2 define dos tipos:

 Intermediario redirector: se trata de un nodo SOAP, el cual redirige el mensaje

SOAP a otro nodo SOAP según lo establecido en un bloque de encabezado que
ha recibido el nodo destino o según el patrón de mensajes en uso.

 Intermediario activo: realiza un procesamiento adicional del mensaje SOAP

antes de redirigirlo, sin utilizar criterios descritos en el encabezado del mensaje o
del patrón de mensajes en uso.

Implementación de un servicio web SOAP[editar]

Todos los lenguajes de uso mayoritario en el desarrollo de sistemas web
implementan o incluyen algún tipo de soporte para la implementación tanto de
web services SOAP como de los clientes que los consumen. Además de
librerías que implementan el protocolo a nivel básico, encontramos otras que
implementan diferentes escenarios de uso y establecen interfaces más
sencillas simplificando la programación.
Estas librerías, utilizadas en conjunto con frameworks de desarrollo de
sistemas web agilizan el proceso de desarrollo tanto del web service como de
sus clientes, en especial si se genera un fichero WSDL que comunique a los
clientes las características del servicio.

 JAVA: dentro de su librería estándar se encuentran implementaciones concretas a

las que se da soporte oficial. También podemos encontrar librerías de terceros
que, tal y como se ha comentado, ayudan al desarrollador simplificando las
 interfaces e implementando los casos de uso más habituales. Cabe destacar que
los IDEs más utilizados ofrecen soporte para la creación de servicios web
SOAP que, entre otras cosas, generan automáticamente el fichero WSDL y
permiten diseñar de forma visual el API y las llamadas que contendrá. En cuanto
el servidor a utilizar, se pueden considerar las opciones típicas en Java: Tomcat,
Glassfish, etc. Aun así, la elección del servidor puede suponer algunas ventajas,
por ejemplo, Glassfish genera una sencilla interfaz web para probar las diferentes
llamadas del servicio. Además, la mayoría de herramientas permiten
la generación del cliente del servicio automáticamente a partir de su fichero
WSDL.

 PHP: ofrece soporte y unas librerías de apoyo habilitando la extensión

SOAP en el servidor. Se ha desarrollado un gran número de librerías de terceros,
que combinadas con el uso de frameworks MVC, simplifican las interfaces e
implementan los escenarios de uso más habituales. También son habituales las
implementaciones de clientes para servicios web públicos concretos.

 Python: no ofrece un soporte en sus librerías estándar, sin embargo, existe un

gran número de paquetes de terceros que permiten la implementación de
servicios web SOAP y sus clientes. En el ámbito del desarrollo de servicios web
en Python, predomina la utilización del Framework Django que se puede
combinar con cualquiera de las implementaciones de SOAP.

 .NET: dentro del Framework se ofrecen herramientas similares a las de Java para
el diseño visual del servicio y la creación automática de WSDL . También da
soporte para la creación de los clientes a partir del fichero de definición del
servicio. En el caso de .NET, el IDE destacado es Visual Studio. En cuanto a
librerías encontramos que el ecosistema .NET ofrece múltiples opciones en varios
lenguajes, aunque la apuesta actual de Microsoft para el desarrollo web es
su Framework .NET MVC. Se debe tener en cuenta, que Microsoft creó el
formato Windows Communication Foundation que es un modelo para la
creación de sistemas orientados a servicios, similar y complementario al WSDL.
JSON
Ir a la navegaciónIr a la búsqueda

JSON

https://json.org/, https://json.org/json-fr.html y https://json.org/json-
it.html

Información general

Extensión de archivo .json

Tipo de MIME application/json

Tipo de formato Lenguaje de marcado

Extendido de JavaScript

Estándar(es) RFC 7159, ECMA-404

Formato abierto ?

[editar datos en Wikidata]

Douglas Crockford fue el primero en especificar y popularizar el JSON

JSON (acrónimo de JavaScript Object Notation, «notación de objeto de

JavaScript») es un formato de texto sencillo para el intercambio de datos. Se trata
de un subconjunto de la notación literal de objetos de JavaScript, aunque, debido
a su amplia adopción como alternativa a XML, se considera (año 2019) un formato
independiente del lenguaje.
Una de las supuestas ventajas de JSON sobre XML como formato de intercambio
de datos es que resulta mucho más sencillo escribir un analizador
sintáctico (parser) para él. En JavaScript, un texto JSON se puede analizar
fácilmente usando la función  eval() , algo que (debido a la ubicuidad de
JavaScript en casi cualquier navegador web) ha sido fundamental para que haya
sido aceptado por parte de la comunidad de desarrolladores AJAX.
En la práctica, los argumentos a favor de la facilidad de desarrollo de analizadores
o de sus rendimientos son poco relevantes, debido a las cuestiones de seguridad
que plantea el uso de  eval()  y el auge del procesamiento nativo de XML
incorporado en los navegadores modernos. Por esa razón, JSON se emplea
habitualmente en entornos donde el tamaño del flujo de datos entre cliente y
servidor es de vital importancia (de aquí su uso por Yahoo!, Google, Mozilla, etc,
que atienden a millones de usuarios) cuando la fuente de datos es explícitamente
de fiar y donde no es importante el hecho de no disponer de
procesamiento XSLT para manipular los datos en el cliente.
Si bien se tiende a considerar JSON como una alternativa a XML, lo cierto es que
no es infrecuente el uso de JSON y XML en la misma aplicación; así, una
aplicación de cliente que integra datos de Google Maps con datos meteorológicos
en SOAP necesita hacer uso de ambos formatos.
En diciembre de 2005, Yahoo! comenzó a dar soporte opcional de JSON en
algunos de sus servicios web.1
 Índice

 1Nombre y pronunciación
 2Sintaxis
 3Modelos de procesamiento
 4Uso de JSON
 5Ejemplo de JSON
 6Comparación con XML y otros lenguajes de marcado
 7Véase también
 8Referencias
 9Enlaces externos

Nombre y pronunciación[editar]
En inglés, JSON se pronuncia de forma acronímica, como el nombre de la
letra J (jay, [dʒeɪ]) seguido de la sílaba «son». El resultado habitual, con la primera
sílaba tónica ([ˈdʒeɪsən]), se pronuncia igual que el nombre Jason,
aunque Douglas Crockford, desarrollador del formato JSON, marca como tónica la
segunda sílaba, como [dʒeɪˈsɒn].2
En español, se ha adaptado de varias maneras:

 /ˈ͡ɟʝei̯ son/ («yéison»), por adaptación fonética del acrónimo en inglés como
"Yeison Bill";
 /xotaˈson/ («jotasón»), como un calco del original solo que con el nombre
de la letra J en español (jota).3

Sintaxis[editar]
Los tipos de datos disponibles con JSON son:

 Números: Se permiten números negativos y opcionalmente pueden

contener parte fraccional separada por puntos. Ejemplo: 123.456
 Cadenas: Representan secuencias de cero o más caracteres. Se ponen
entre doble comilla y se permiten cadenas de escape. Ejemplo:  "Hola"
 Booleanos: Representan valores booleanos y pueden tener dos
valores:  true  y  false
 null: Representan el valor nulo.
 Array: Representa una lista ordenada de cero o más valores los cuales
pueden ser de cualquier tipo. Los valores se separan por comas y el vector se
mete entre corchetes. Ejemplo  ["juan","pedro","jacinto"]
 Objetos: Son colecciones no ordenadas de pares de la
forma <nombre>:<valor> separados por comas y puestas entre llaves. El
nombre tiene que ser una cadena y entre ellas. El valor puede ser de cualquier
 tipo. Ejemplo:  {"departamento":8,"nombredepto":"Ventas","director":
"juan rodriguez","empleados":
[{"nombre":"Pedro","apellido":"Fernandez"},
{"nombre":"Jacinto","apellido":"Benavente"} ]}

Modelos de procesamiento[editar]
Al ser JSON un formato muy extendido para el intercambio de datos, se han
desarrollado API para distintos lenguajes (por ejemplo ActionScript, C, C+
+, C#, ColdFusion, Common
Lisp, Delphi, E, Eiffel, Java, JavaScript, ML, Objective-C, Objective
CAML, Perl, PHP, Python, Rebol, Ruby, Lua y Visual FoxPro) que permiten
analizar sintácticamente, generar, transformar y procesar este tipo de dato.
Los modelos de programación más utilizados para tratar con JSON en los distintos
lenguajes son:4

 Modelo de objeto.- El JSON completo es almacenado en memoria en un

formato de árbol. Este árbol es navegado, analizado y modificado con las API
apropiadas. Como lo carga todo en memoria y luego lo procesa este modelo
consume muchos recursos. Sin embargo es muy flexible para manipular el
contenido. Este modelo es permitido por ejemplo en Java por la JSR 353 y por
la biblioteca Jackson.
 Modelo de flujo: Los datos son leídos o escritos en bloques. Por ejemplo,
cada vez que se lee un bloque, el analizador genera eventos apropiados para
indicar el tipo de bloque de que se trata. El cliente puede procesar el contenido
escuchando los eventos apropiados. Además es el cliente el que decide como
se va leyendo el JSON permitiendo parar o saltar contenidos en mitad del
proceso. El proceso de escritura tiene propiedades análogas. Por ejemplo este
modelo es permitido en java por la JSR 353.
 Convirtiendo los objetos JSON en objetos del lenguaje. En Java esto es
realizado por ejemplo por las bibliotecas Jackson y Gson.

Uso de JSON[editar]
En teoría, es trivial analizar JSON en JavaScript usando la
función  JSON.parse()  incorporada en el lenguaje. Por ejemplo:

miObjeto = JSON.parse(json_datos);

En la práctica, las consideraciones de seguridad por lo general recomiendan no

usar eval sobre datos crudos y debería usarse un analizador JavaScript distinto
para garantizar la seguridad. El analizador proporcionado por JSON.org
usa  eval()  en su función de análisis, protegiéndola con una expresión regular de
forma que la función sólo ve expresiones seguras.
Un ejemplo de acceso a datos JSON usando XMLHttpRequest es:

var http_request = new XMLHttpRequest();

var url = "http://example.net/jsondata.php"; // Esta URL debería devolver
datos JSON

// Descarga los datos JSON del servidor.

http_request.onreadystatechange = handle_json;
http_request.open("GET", url, true);
http_request.send(null);

function handle_json() {
if (http_request.readyState == 4) {
if (http_request.status == 200) {
var json_data = http_request.responseText;
var the_object = eval("(" + json_data + ")");
} else {
alert("Ocurrió un problema con la URL.");
}
http_request = null;
}
}

Obsérvese que el uso de XMLHttpRequest en este ejemplo no es compatible con

todos los navegadores, ya que existen variaciones sintácticas para Internet
Explorer, Opera, Safari, y navegadores basados en Mozilla.
También es posible usar elementos  <iframe>  ocultos para solicitar los datos de
manera asíncrona, o usar peticiones  <form target="url_to_cgi_script" /> .
Estos métodos eran los más habituales antes del advenimiento del uso
generalizado de XMLHttpRequest.
Hay una biblioteca5 para el framework .NET que exporta clases .NET con la
sintaxis de JSON para la comunicación entre cliente y servidor, en ambos
sentidos.

Ejemplo de JSON[editar]
A continuación se muestra un ejemplo simple de definición de barra de menús
usando JSON y XML.
JSON:

{
"menu": {
"id": "file",
"value": "File",
"popup": {
"menuitems": [
{
"value": "New", "onclick": "CreateNewDoc()"
 },{
"value": "Open", "onclick": "OpenDoc()"
},{
"value": "Close", "onclick": "CloseDoc()"
}
]
}
}
}

Es una posible representación JSON del siguiente XML:

<menu id="file" value="File">

<popup>
<menuitem value="New" onclick="CreateNewDoc()" />
<menuitem value="Open" onclick="OpenDoc()" />
<menuitem value="Close" onclick="CloseDoc()" />
</popup>
</menu>

Comparación con XML y otros lenguajes de

marcado[editar]
Hay muchos analizadores JSON en el lado del servidor, existiendo al menos un
analizador para la mayoría de los entornos. En algunos lenguajes, como Java
o PHP, hay diferentes implementaciones donde escoger. En JavaScript, el análisis
es posible de manera nativa con la función  JSON.parse() . Ambos formatos
carecen de un mecanismo para representar grandes objetos binarios.
Con independencia de la comparación con XML, JSON puede ser muy compacto y
eficiente si se usa de manera efectiva. Por ejemplo, la aplicación DHTML de
búsqueda en «BarracudaDrive» (en inglés). Archivado desde el original el 21 de
mayo de 2006. recibe los listados de directorio como JSON desde el servidor. Esta
aplicación de búsqueda está permanentemente consultando al servidor por
nuevos directorios, y es notablemente rápida, incluso sobre una conexión lenta.
Los entornos en el servidor normalmente requieren que se incorpore una función u
objeto analizador de JSON. Algunos programadores, especialmente los
familiarizados con el lenguaje C, encuentran JSON más natural que XML, pero
otros desarrolladores encuentran su escueta notación algo confusa, especialmente
cuando se trata de datos fuertemente jerarquizados o anidados muy
profundamente.
Hay más comparaciones entre JSON y XML en JSON.org 6
YAML es un superconjunto de JSON que trata de superar algunas de las
limitaciones de éste. Aunque es significativamente más complejo, 7 aún puede
considerarse como ligero. El lenguaje de programación Ruby utiliza YAML como el
formato de serialización por defecto. Así pues, es posible manejar JSON con
bastante sencillez.