iphone - JSON o SOAP(XML)?
objective-c (7)
Ah, la gran pregunta: ¿ JSON o XML ?
En general, preferiría XML solo cuando necesite pasar una gran cantidad de texto, ya que XML se destaca al envolver y marcar texto.
Al pasar alrededor de pequeños objetos de datos, donde las únicas cadenas son pequeñas (identificadores, fechas, etc.), tendería a usar JSON, ya que es más pequeño, más fácil de analizar y más legible.
Además, tenga en cuenta que incluso si elige XML, eso no significa que deba usar SOAP. SOAP es un protocolo muy pesado, diseñado para la interoperabilidad entre socios. Como controlas tanto el cliente como el servidor aquí, no necesariamente tiene sentido.
Estoy desarrollando una nueva aplicación para la compañía. La aplicación tiene que intercambiar datos desde y hacia el iPhone.
La parte del servidor de la compañía usa .NET framework.
Por ejemplo: la clase "Cliente" (Nombre, Dirección, etc.) para un ClienteNúmero específico debe descargarse primero del servidor al iPhone, almacenarse localmente y luego cargarse nuevamente para aplicar los cambios (y ponerlos a disposición de otras personas). La simultaneidad no debería ser un problema (al menos en este momento ...)
En cualquier caso, tengo que desarrollar tanto el lado del servidor (servicio web o lo que sea) y la aplicación de iPhone.
Soy libre de identificar la mejor manera de hacerlo (esta es la aplicación "número UNO", por lo que se convertirá en el "estándar" para el futuro).
Entonces, ¿qué me sugieres?
Use servicios web SOAP (análisis XML, etc.) o el usuario JSON? (parece más claro ...) ¿Tengo claro cómo "cargar" datos usando SOAP (muy largo para codificar el sobre de xml soap ... lo evitaría) pero ¿cómo puedo hacer lo mismo usando JSON?
La aplicación necesita usar valores de fecha (por ejemplo: last_visit_date, etc.) ¿qué pasa con la fecha en Json?
Considera cómo estarías consumiendo los resultados en el iPhone. ¿Qué menester usarías para leer la respuesta del servicio web? NSXMLParser?
La forma en que consuma los datos tendría el mayor impacto en la forma en que la sirve.
¿JSON y SOAP son sus únicas opciones? ¿Qué pasa con los servicios RESTful?
Eche un vistazo a algunos grandes jugadores en la web que tienen API públicas a las que pueden acceder los clientes de iPhone:
Además, revise los siguientes artículos relacionados:
Definitivamente iría con JSON, como ya se señaló, es más rápido y el tamaño de los datos es menor. También puede usar un marco de modelado de datos como JSONModel para validar la estructura JSON y para autoconvertir objetos JSON en objetos Obj-C.
JSONModel también incluye clases para trabajar en red y trabajar con API; también incluye métodos json rpc.
Eche un vistazo a estos enlaces:
- http://www.jsonmodel.com - el marco JSONModel
- http://json-rpc.org - especificación para la implementación de API JSON
- http://www.charlesproxy.com - la mejor herramienta para depurar API JSON
- http://json-schema.org - herramienta para definir esquemas de validación para JSON, útil en el camino
Breve ejemplo del uso de JSONModel: http://www.touch-code-magazine.com/how-to-make-a-youtube-app-using-mgbox-and-jsonmodel/
Espero que estos sean útiles
Hay más opciones que solo SOAP vs JSON. Puede hacer un protocolo basado en REST ( Representational State Transfer ) usando XML. Creo que es más fácil de usar que SOAP y obtienes un XSD mucho mejor (que diseñas). Para casi cualquier cliente, es bastante fácil acceder a dichos servicios.
Por otro lado, los analizadores JSON están disponibles para casi cualquier idioma y hacen que sea muy fácil llamar desde JavaScript si los usa a través de AJAX.
Sin embargo, SOAP puede ser bastante poderoso con toneladas de extensiones estandarizadas que admiten funciones empresariales.
JSON tiene las siguientes ventajas:
- puede codificar valores booleanos y numéricos ... en XML todo es una cadena
- tiene una semántica mucho más clara ... en json tienes
{"key":"someValue"}, en XML puedes tener<data><key>someValue</key></data>o<data key="someValue" />... cualquier nodo XML debe tener un nombre ... esto no siempre tiene sentido ... y los niños pueden representar las propiedades de un objeto, o niños, que cuando ocurren varias veces en realidad representan una matriz ... a realmente entiendo la estructura de objetos de un mensaje XML, necesita su esquema correspondiente ... en JSON, solo necesita el JSON ... - más pequeño y por lo tanto utiliza menos ancho de banda y memoria durante el análisis / generación ...
aparte de eso, no veo NINGUNA diferencia entre XML y JSON ... quiero decir, esto es tan intercambiable ... puedes usar JSON para capturar la semántica de SOAP, si quieres ... es solo que SOAP está tan hinchado ... si quieres usar SOAP, utiliza una biblioteca y generadores para eso ... no es divertido ni interesante construirlo todo a mano ...
utilizando XML RPC o JSON RPC debería funcionar más rápido ... es más liviano, y usa JSON o XML a voluntad ... pero al crear aplicaciones cliente <-> servidor, algo muy importante a mis ojos, es abstraer el capa de transporte en ambos lados ... toda la lógica de su negocio, etc., de ninguna manera debe depender de más que una pequeña interfaz, cuando se trata de comunicación, y luego puede conectar los protocolos en su aplicación, según sea necesario ...
JSON tiene varias ventajas sobre XML. Es mucho más pequeño y menos hinchado, por lo que pasará mucha menos información a través de la red, lo que en el caso de un dispositivo móvil hará una diferencia considerable.
También es más fácil de usar en el código de JavaScript, ya que simplemente puede pasar el paquete de datos directamente a una matriz de javascript sin ningún tipo de análisis, extracción y conversión, por lo que también consume menos CPU.
Para codificar con él, en lugar de una biblioteca XML, querrá una biblioteca JSON. Las fechas se manejan como lo haría con XML: codifíquelas en un estándar y luego deje que la biblioteca las reconozca. (por ejemplo, aquí hay una biblioteca con una muestra con fechas)
También puede usar Hessian usando HessianKit en el lado del iPhone, y HessianC # en el lado del servidor.
Los grandes bonos son: 1. Hessian en un protocolo de serialización binario, por lo que las cargas útiles de datos más pequeñas, son buenas para 3G y GSM. 2. No necesita preocuparse por el formato en ninguno de los extremos, el transporte está automatizado con proxies.
Entonces, en el lado del servidor, simplemente define una interfaz C #, como por ejemplo:
public interface IFruitService {
int FruitCount();
string GetFruit(int index);
}
Luego, usted solo subclona CHessianHandler e implementa IFruitService, y su servicio web finaliza.
En el iPhone solo escribe el protocolo Objective-C correspondiente:
@protocol IFruitService
-(int)FruitCount;
-(NSString*)GetFruit:(int)index;
@end
A continuación, puede accederse por proxy mediante una única línea de código:
id<IFruitService> fruitService = [CWHessianConnection proxyWithURL:serviceURL
protocol:@protocol(IFruitService)];
Campo de golf:
HessianKit: hessiankit