Download - MMS REST API Developers Guide

de 32 movistar © 2009 Reservados todos los derechos.

Guía del API MMS REST


Contenido

1 INTRODUCCIÓN ................................................................................................................... 4

1.1 ALCANCE ...................................................................................................................... 4

1.2 GLOSARIO .................................................................................................................... 4

2 CONVENCIONES GENERALES ........................................................................................... 5

2.1 PAUTAS GENERALES DE UNA INTERFAZ REST ..................................................... 5

2.2 CONSIDERACIONES ESPECÍFICAS PARA LA API REST DE MMS ......................... 5

2.2.1 Consideraciones de Seguridad ................................................................................. 7

2.3 CODIFICACIÓN Y DETALLES DE SERIALIZACIÓN ................................................... 8

2.3.1 Codificación para el envío de un MMS: Uso de Formularios .................................... 8

3 DEFINICIÓN DE LAS OPERACIONES ............................................................................... 11

3.1 ENVÍO DE MMS .......................................................................................................... 11

3.1.1 Petición .................................................................................................................... 11

3.1.2 RESPUESTA ........................................................................................................... 14

3.2 CONSULTA DEL ESTADO DE ENVÍO ....................................................................... 15

3.2.1 PETICIÓN ................................................................................................................ 15

3.2.2 Respuesta ............................................................................................................... 16

4 NAMESPACES .................................................................................................................... 18

5 DEFINICIÓN DE TIPOS DE DATOS ................................................................................... 19

5.1 ESTRUCTURA DEL MessageType ............................................................................ 19

5.2 ESTRUCTURA DEL MessageResultType .................................................................. 19

5.3 ESTRUCTURA DEL MessageDeliveryStatusPollType ............................................... 19

5.4 ESTRUCTURA DEL MessageDeliveryStatusType ..................................................... 20

5.5 ENUMERACIÓN DEL MessagePriorityType .............................................................. 20

5.6 ESTRUCTURA DEL DeliveryInformationType ............................................................ 20

5.7 ENUMERACIÓN DEL DeliveryStatusType ................................................................. 20

5.8 ENUMERACIÓN DEL AltType .................................................................................... 21

5.9 OPCIÓN UserIdType ................................................................................................... 21

6 LIBRERÍAS CLIENTE DE USO DE LAS APIS .................................................................... 22

6.1 CLIENTE JAVA ........................................................................................................... 22

6.1.1 Directrices de Programación ................................................................................... 22

6.1.2 Ejemplo para el envío con el cliente MMS .............................................................. 22

6.1.3 Paquetes del Cliente ............................................................................................... 24

6.1.4 Prerrequisitos .......................................................................................................... 24

6.2 CLIENTE C# ................................................................................................................ 24


6.2.2 Ejemplo para el envío con el cliente MMS .............................................................. 25


6.2.4 Prerrequisitos .......................................................................................................... 26

6.3 CLIENTE PHP ............................................................................................................. 26

6.3.1 Dependencias .......................................................................................................... 26


6.3.3 Esta librería se ha probado en los siguientes sistemas operativos: CentOs 5, Fedora 11, Ubuntu Jaunty, Ubuntu Karmic, Debian Lenny, Windows 7 y Windows XP.Ejemplo para el envío con el cliente MMS ..................................................................... 27



7 DETALLE DE LAS DESCRIPCIONES DE ERROR ............................................................ 29

A CONSIDERACIONES GENERALES ................................................................................... 30

A.1 Métodos HTTP ............................................................................................................ 30

A.1.1 POST ....................................................................................................................... 30

A.1.2 GET ......................................................................................................................... 30

A.1.3 PUT.......................................................................................................................... 30

A.1.4 DELETE ................................................................................................................... 31

A.2 REPRESENTACIONES COMUNES ........................................................................... 31

A.2.1 JSON ....................................................................................................................... 31

A.2.2 XML ......................................................................................................................... 31

B REFERENCIAS .................................................................................................................... 32


1 INTRODUCCIÓN Este documento sirve como guía para el uso de la API REST de envío de MMS que proporciona Movistar Developers PlatformBETA. Las funcionalidades que se exponen son el envío de MMS y la consulta del estado de envío de un MMS. Estas funcionalidades se exponen a través de una interfaz REST (REpresentational State Transfer) que expone el servicio simplificando las peticiones a través de sencillas peticiones HTTP.

1.1 ALCANCE

El API MMS de Movistar Developers PlatformBETA permite el envío de mensajes MMS a los siguientes países.

• MÉXICO

1.2 GLOSARIO

• API: Application Programming Interface

• ID: Identifier

• HTTPS: HyperText Transfer Protocol Secure

• JSON: JavaScript Object Notation

• REST: Representational State Transfer

• MMS: Multimedia Messaging Service

• URI: Uniform Resource Identifier

• URL: Uniform Resource Locator

• WSDL: Web Services Description Language

• XML: eXtended Markup Language


2 CONVENCIONES GENERALES

2.1 PAUTAS GENERALES DE UNA INTERFAZ REST

REST (REpresentational States Transfer) es un estilo de arquitectura basado en los siguientes principios: - Direccionabilidad: Los recursos son expuestos mediante URIs.

- Sin Estado. Las peticiones a los recursos son independientes una de la otra.

- Conectividad. Los recursos pueden incluir enlaces a otros recursos.

- Una interfaz uniforme: Las operaciones permitidas son obtención, creación,

modificación y eliminación de recursos utilizando el protocolo HTTP. La implementación de estos pilares da como resultado servicios RESTful que se basan en el protocolo HTTP, son independientes del lenguaje, pueden usarse en presencia de firewalls, las aplicaciones pueden cachearlos, son altamente escalables, etc. REST tiene como propósito la implementación de servicios ligeros, inteligibles y fácilmente implementables que se definen en base a una serie de operaciones RESTful, que implica el intercambio de información acorde a los formatos de los datos REST.

2.2 CONSIDERACIONES ESPECÍFICAS PARA LA API REST DE MMS

1. La petición de envío de MMS es una petición POST que se puede hacer con los siguiente Content-Types: - application/xml - application/json - application/x-www-form-urlencoded (soportado, aunque se recomienda usar

XML o JSON)

2. La respuesta a esa petición irá en el formato expresado en la petición, excepto cuando la petición sea url-encoded, en cuyo caso las respuestas serán XML.

3. La petición de MessageDeliveryStatus es una petición GET, en la que se indica el MMS a consultar a través de un parámetro indicado en la URI que forma la petición. Por defecto la respuesta tiene formato XML, aunque se puede pedir que la respuesta esté en formato JSON a través de un parámetro “alt”, incluido en la URI que forma la petición.

4. Mapeo de XML a JSON. Puesto que XML es el formato por defecto utilizado en la API de MMS, se incluyen archivos XSD que describen los datos necesarios para invocar al API mediante XML. Para pasar estas representaciones a formato JSON, se presentan las siguientes reglas de aplicación general:

a. Los elementos XML que aparecen al mismo nivel jerárquico XML (tanto los elementos de primer nivel como los que están dentro del mismo elemento XML padre), se mapean a un conjunto de pares nombre:valor dentro de un objeto JSON, como se describe a continuación:


i. Cada elemento XML que aparece una sola vez en el mismo nivel jerárquico se mapea a un par nombre:valor individual. El nombre se forma de acuerdo al punto b, mientras que el valor se forma de acuerdo al punto c.

ii. Elementos XML que aparezcan más de una vez en el mismo nivel jerárquico se mapean a un único par nombre:valor individual. El nombre se forma de acuerdo al punto b, mientras que el valor is un array JSON que contiene un valor por cada ocurrencia del elemento XML. El nombre se forma de acuerdo al punto b, mientras que los valores se forman de acuerdo al punto c.

iii. El nombre y el valor de los objetos JSON irán entre comillas “”. Además, cualquier representación JSON irá entre llaves {}, de acuerdo a la RFC de JSON.

b. El nombre del par nombre:valor es el nombre de los elementos XML (nombre_elemento_XML:valor).

c. El valor se forma como se describe a continuación: i. Cuando el elemento XML no tiene ni atributos ni elementos XML hijos,

el valor es igual al valor del elemento XML. En caso de que el elemento sea nulo (no tenga valor), se indicará poniendo un valor “null” en el JSON.

ii. Cuando el elemento XML tenga elementos hijos y/o atributos, el valor es un objeto JSON que contiene los siguientes pares nombre:valor :

• Un par nombre:valor por cada atributo, donde el nombre es el nombre del atributo y el valor es el valor del atributo.

• Un par nombre:valor asociado al valor del elemento XML, donde nombre es la cadena “$t” y valor es el valor del elemento XML. Nota: no hay una regla específica sobre esto en la RFC de JSON o en json.org. Por tanto, se ha seleccionado la cadena “$t” en base a las reglas de Google para conversión de feeds XML a JSON (http://code.google.com/intl/es/apis/gdata/json.html).

• Pares nombre:valor asociados a elementos XML hijos. Estos pares nombre:valor se forman de acuerdo al punto a.

Dentro de JSON no es necesario reflejar: i. El primer tag <?xml verion="1.0" encoding="UTF-8" ? ii. Declaración de namespaces o schemaLocations.

Ejemplo de transformación XML a JSON.

<Animals>

<dog>

<name attr="1234">Rufus</name>

<BReed>labrador</BReed>

</dog>

<dog>

<name>Marty</name>

<BReed>whippet</BReed>

<a/>

</dog>

<dog/>

<cat name="Matilda"/>

<a/>

</Animals>

{"Animals": {

"a": null,


"cat": {"name": "Matilda"},

"dog": [

{

"BReed": "labrador",

"name": {

"$t": "Rufus",

"attr": "1234"

}

},

{

"BReed": "whippet",

"a": null,

"name": "Marty"

},

null

]

}}

2.2.1 Consideraciones de Seguridad

El siguiente punto detalla las consideraciones de seguridad que se deben tener en cuenta en las aplicaciones desarrolladas para acceder a la API de MMS REST. La aplicaciones deben incluir un Authorization header en cada petición HTTP. El encabezado contendrá los siguientes datos:

Authorization: SDPBasicAuth realm="SDPAPIs", consumer_key=

"serviceId@spId", signature_method="MD5",

signature="MD5(spId+spPassword+timeStamp)",

timestamp="YYYYMMDDHHMMSS", version="0.1", token="AccessToken",

requestor_id ="MSISDN ", requestor_type ="1"

Los términos serviceId, spID y spPassword se pueden obtener en la información del desarrollador en la Web de Movistar Developers PlatformBETA. Requestor_id es el MSISDN (número de teléfono) del usuario en nombre del cual la aplicación invocará el API.

AccessToken es un conjunto de 8 caracteres entre los siguientes {a-z, A-Z, 0-9} que el usuario podrá obtener y actualizar en la sección “Mi perfil” del portal de Movistar Developers PlatformBETA y que la aplicación debe incluir en la cabecera Authorization para invocar el API en nombre del usuario.

Puesto que le aplicación debe incluir el requestor_id y token del usuario, es responsabilidad del developer solicitar estos datos al usuario antes de invocar el API de la forma que considere más conveniente.

Un ejemplo de un Authorization Header sería:

Authorization: SDPBasicAuth realm="SDPAPIs", consumer_key=

"35000001000001@35000001", signature_method="MD5",


signature="5b941f30e158d2af2df658dd5acca810",

timestamp="20090902154157 ", version="0.1", token="1x3rs6n8",

requestor_id ="5213907550010", requestor_type ="1"

Cuando una petición HTTP se realiza sin la cabecera Authorization o con un formato incorrecto, se recibirá una respuesta de error HTTP. Sin embargo, si el formato de la cabecera Authorization es correcto pero los valores contenidos en ella son erróneos, se aceptará la petición pero el mensaje no se enviará. Esta situación podrá comprobarse mediante la operación GetMessageDeliveryStatus (ver 3.2 CONSULTA DEL ESTADO DE ENVÍO).

2.3 CODIFICACIÓN Y DETALLES DE SERIALIZACIÓN

Un MMS consiste en diversas partes que pueden contener diversos tipos de contenido. Cualquiera podría ser válido siempre y cuando los contenidos estén asociados con un tipo MIME descrito en el IETF/IANA y permitido de acuerdo con las políticas del operador. Sin embargo, solamente se aconseja el uso de los siguientes tipos de contenidos:

• Texto sin formato

• Imágenes en formatos GIF y JPEG

La estructura del MMS enviado (operación de envío de mensaje) será siempre la misma, un conjunto de campo fijos raíz, descritos más adelante y los contenidos como un conjunto de adjuntos a esta parte principal. En la versión REST de MMS, la operación de envío de mensajes involucrará un método POST.

2.3.1 Codificación para el envío de un MMS: Uso de Formularios

La codificación de la operación SendMessage implica la inclusión en el cuerpo de la petición HTTP de un contenido de tipo Content-Type: multipart/form-data. A continuación se describen las opciones de implementación:

1. Los campos raíz se incluirán como un único campo de formulario con un cuerpo MIME con las siguientes cabeceras:

Content-Disposition: form-data; name=<root-fields>

Content-Type: <Codificación utilizada >

Las codificaciones permitidas son:

• application/xml

• application/json

• application/x-www-form-urlencoded

2. Los contenidos multimedia del mensaje se incluirán utilizando una de las siguientes opciones:

a. Cuando el MMS contiene más de un contenido se incluirá un campo de formulario con un cuerpo MIME con las siguientes cabeceras:

Content-Disposition: form-data; name=”attachments”

Content-Type: multipart/mixed

De esta forma, cada uno de los contenidos del MMS se incluirán como subpartes, con las siguientes cabeceras:

Content-Disposition: attachment; filename=”<nombre del contenido>”


Content-Type: <Content-Type correspondiente al tipo de contenido>

b. Cuando el MMS contiene un único contenido se incluirá un cuerpo MIME con las siguientes cabeceras:

Content-Disposition: form-data; name=”attachments”; filename=”<nombre del contenido>”

Content-Type: <Content-Type correspondiente al tipo de contenido>

3. Para cada parte y subparte del cuerpo HTTP, es posible incluir otros parámetros (Content-Description, Content-Transfer-Encoding, etc.).

A continuación se muestra un ejemplo de cómo codificar un MMS utilizando formularios cuando los root fields tienen formato XML y se envía más de un contenido multimedia:

POST https://telefonica.com/gSDP/UNICA-MMS-REST/MMS HTTP/0.1

Other http headers

Content-Type: multipart/form-data, boundary=asdfa487

--asdfa487

Content-Disposition: form-data; name=”root-fields”

Content-type: application/xml

Insertar aquí la representación XML de los root fields del MMS

--asdfa487

Content-disposition: form-data; name="attachments"

Content-type: multipart/mixed, boundary=BbC04y

--BbC04y

Content-disposition: attachment; filename="textBody.txt"

Content-Type: text/plain; charset= “UTF-8”

Content-Transfer-Encoding: 8-bit

... texto del MMS ...

--BbC04y

Content-disposition: attachment; filename="file2.gif"

Content-type: image/gif

Content-Transfer-Encoding: base64

...contenido de file2.gif...

--BbC04y

Aquí pueden venir otros adjuntos (correctamente delimitados por

el boundary)

--BbC04y--

--asdfa487--

A continuación se muestra un ejemplo de cómo codificar un MMS utilizando formularios cuando los root fields tienen formato JSON y se envía un único contenido multimedia:

POST https://telefonica.com/gSDP/UNICA-MMS-REST/MMS HTTP/1.1

Other http headers

Content-Type: multipart/form-data, boundary=asdfa487


--asdfa487

Content-Disposition: form-data; name=”root-fields”

Content-Type: application/json

Insertar aquí la representación JSON de los root fields del MMS

--asdfa487

Content-disposition: form-data; name="attachments";

filename=”picture.jpeg”

Content-type: image/jpeg

…contenido de picture.jpeg…

--asdfa487


3 DEFINICIÓN DE LAS OPERACIONES En este punto se describen las operaciones de envío y consulta de recepción de mensajes. A través de la API no sólo se pueden enviar MMS sino que también se puede consultar el resultado de la petición. Las operaciones disponibles con el tipo de datos a la entrada y a la salida se describen en el siguiente cuadro.

3.1 ENVÍO DE MMS

3.1.1 Petición

Algunos ejemplos de peticiones con diferentes Content-Type:

Content-Type: application/json POST /osg/UNICA-MMS-REST/MMS HTTP/1.1

Authorization: SDPBasicAuth realm="SDPAPIs",

consumer_key="0100114500@000137", signature_method="MD5",

signature="633C918D5AC2EB63BD3F973FF614C61A",

timestamp="20091023183709", version="0.1", token="czzwlpps",

requestor_id="5213907550006", requestor_type="1"

User-Agent: Jakarta Commons-HttpClient/3.1

Host: 200.39.21.12:8443

Content-Length: 9734

Content-Type: multipart/form-data; boundary=fQMP-

v24RkjllGYuGla4vMbYU03EWci

--fQMP-v24RkjllGYuGla4vMbYU03EWci

Content-Disposition: form-data; name="root-fields"


Content-Transfer-Encoding: 8bit

{"message": {

"address": {"phoneNumber": "5213851866417"},

"priority": "Normal",

"subject": "This is the subject"

}}

--fQMP-v24RkjllGYuGla4vMbYU03EWci

Content-Disposition: form-data; name="attachments"

Operación Entrada Salida Send Message MessageType MessageResultType Get Message Delivery Status

MessageDeliveryStatusPollType

MessageDeliveryStatusType

Operación Entrada HTTP Method POST URL https://200.39.21.12:8443/osg/UNICA-MMS-

REST/MMS Content Los formatos de codificación son los siguientes:

application/xml application/json application/x-www-form-urlencoded


Content-Type: multipart/mixed; boundary=----------------

314159265358979323846

------------------314159265358979323846

Content-Disposition: attachment

Content-Type: text/plain


This is the message content.

------------------314159265358979323846

Content-Disposition: attachment; filename="Movistar_logo.jpg"

Content-Type: image/jpeg


/9j/4AAQSkZJRgABAQEAZABkAAD/4Q3fRXhpZgAASUkqAAgAAAACADIBAgAUAAAAJgAAAG

mHBAAB

AAAAOgAAAEAAAAAyMDA5OjA5OjI5IDEyOjI1OjE3AAAAAAAAAAMAAwEEAAEAAAAGAAAAAQ

IEAAEA

AABqAAAAAgIEAAEAAABtDQAAAAAAAP/Y/+AAEEpGSUYAAQEAAAEAAQAA/9sAQwAGBAUGBQ

QGBgUG

BwcGCAoQCgoJCQoUDg8MEBcUGBgXFBYWGh0lHxobIxwWFiAsICMmJykqKRkfLTAtKDAlKC

ko/9sA

QwEHBwcKCAoTCgoTKBoWGigoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKC

goKCgo

KCgoKCgoKCgo/8AAEQgAYACHAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAg

MEBQYH

[…]

qOp+FtVjlmvH8u6UXNzGFkk2KdpYDrg5wa8qvdU1DUWJvb24uMuXxLIWAJ6kA9K6R/iJft

cWMq6d

YxLYCRYY4lZUCuu3GM9hXI06FJxbcl/V2TWqKS0/rYKKKK6jnCiiigD/2Q==

------------------314159265358979323846--

--fQMP-v24RkjllGYuGla4vMbYU03EWci--

Content-Type: application/x-www-form-urlencoded POST /osg/UNICA-MMS-REST/MMS HTTP/1.1



signature="691BED1E294B2BA243DE89D3A8619323",




Host: 200.39.21.12:8443


Content-Type: multipart/form-data;

boundary=7t1LH8y8yT_cjJRgK1cRT9rjALMS498q9_

--7t1LH8y8yT_cjJRgK1cRT9rjALMS498q9_


Content-Type: application/x-www-form-urlencoded


address.phoneNumber=5213851866417&subject=This+is+the+subject&priority

=Normal

--7t1LH8y8yT_cjJRgK1cRT9rjALMS498q9_



314159265358979323846


------------------314159265358979323846





------------------314159265358979323846





mHBAAB


IEAAEA


QGBgUG


ko/9sA

[…]


cWMq6d


------------------314159265358979323846--

--7t1LH8y8yT_cjJRgK1cRT9rjALMS498q9_--

Content-Type: application/xml POST /osg/UNICA-MMS-REST/MMS HTTP/1.1



signature="829817AF9498B752882D9C18138C0E8E",




Host: 200.39.21.12:8443


Content-Type: multipart/form-data; boundary=hePZ5eSi-

JtezYt1hFTDu86N_mj8bbSh

--hePZ5eSi-JtezYt1hFTDu86N_mj8bbSh


Content-Type: application/xml


<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<ns0:message

xmlns:ns0="http://www.telefonica.com/UNICA/mms_bodies/v0_1_1_LITMUS_LA

TAM_03102009"

xmlns:ns1="http://www.telefonica.com/UNICA/mms_types/v0_1_1_LITMUS_LAT

AM_03102009"

xmlns:ns2="http://www.telefonica.com/UNICA_CommonTypes/v0_1">

<ns1:address>

<ns2:phoneNumber>5213851866417</ns2:phoneNumber>

</ns1:address>

<ns1:subject>This is the subject</ns1:subject>

<ns1:priority>Normal</ns1:priority>

</ns0:message>

--hePZ5eSi-JtezYt1hFTDu86N_mj8bbSh




314159265358979323846

------------------314159265358979323846





------------------314159265358979323846





mHBAAB


IEAAEA


QGBgUG


ko/9sA

[…]


cWMq6d


------------------314159265358979323846--

--hePZ5eSi-JtezYt1hFTDu86N_mj8bbSh--

3.1.2 RESPUESTA

En caso de producirse algún error relacionado con:

- spId o serviceId no válidos

- spPassword no válido

- La aplicación no tiene permisos para utilizar el API

- Parámetros no válidos

- Violación de los SLA

se responderá con un código de estado HTTP del tipo 4XX/5XX.

Sin embargo, si de produce un error relacionado con:

- token no válido

Operación Entrada HTTP Response Code 201 Created Content-Type Headers Application/json, si la petición incluyó el

contenido en JSON Application/xml, si la petición incluyó el contenido en XML o en URLencoded

Location Header Contiene el localizador que permite realizar la operación de consulta de estado de envío.

Body Elemento MessageTextResultType en el formato indicado en la cabecera Content-Type


- El MSISDN no tiene permisos para utilizar el API

se responderá con un código de estado HTTP 201, pero al consultar el estado del envío se obtendrá el valor DeliveryImpossible (ver 3.2 CONSULTA DEL ESTADO DE ENVÍO).

Algunos ejemplos de respuestas con diferentes Content-Type:


HTTP/1.1 201 Created

Server: Apache-Coyote/1.1

Location: https://200.39.21.12:8443/osg/UNICA-MMS-

REST/MMS/MessageDeliveryStatus?messageIdentifier=10000910231637354403

Content-Type: application/json;charset=ISO-8859-1

Content-Length: 61

Date: Fri, 23 Oct 2009 16:37:35 GMT

{"messageResult":{"mmsMessageResult":"10000910231637354403"}}

Content-Type: application/xml

HTTP/1.1 201 Created


Location: https://200.39.21.12:8443/osg/UNICA-MMS-


Content-Type: application/xml;charset=ISO-8859-1

Content-Length: 268

Date: Fri, 23 Oct 2009 16:33:42 GMT

<v0:messageResult

xmlns:v0="http://www.telefonica.com/UNICA/mms_bodies/v0_1_1_LITMUS_LAT

AM_03102009">

<v01:mmsMessageResult

xmlns:v01="http://www.telefonica.com/UNICA/mms_types/v0_1_1_LITMUS_LAT

AM_03102009">

10000910231633424183

</v01:mmsMessageResult>

</v0:messageResult>

3.2 CONSULTA DEL ESTADO DE ENVÍO

3.2.1 PETICIÓN

La URL necesaria para la petición de consulta se obtiene en el header de Location incluido en la respuesta a la operación SendMessage.

Operación Entrada HTTP Method GET URL https://200.39.21.12:8443/osg/UNICA-MMS-

REST/MessageDeliveryStatus Content La petición GET de consulta no incluye body, la

información necesaria debe ser pasada como parámetros de consulta.


Ejemplo de una petición de consulta del Estado de Envío con respuesta en XML

GET /osg/UNICA-MMS-


HTTP/1.1



signature="376B82EBC709531FA8119C0F431A784C",




Host: 200.39.21.12:8443

Ejemplo de una petición de consulta del Estado de Envío con respuesta en JSON

GET /osg/UNICA-MMS-

REST/MMS/MessageDeliveryStatus?messageIdentifier=10000910231637354403&

alt=JSON HTTP/1.1



signature="B884B4137807EC0EA8E17AA72DBFC6F2",




Host: 200.39.21.12:8443

3.2.2 Respuesta

Ejemplo de una respuesta en JSON HTTP/1.1 200 OK


Content-Type: application/json;charset=ISO-8859-1

Content-Length: 136

Date: Fri, 23 Oct 2009 16:37:37 GMT

{"messageDeliveryStatus":{"mmsMessageDeliveryStatus":{"address":{"anyU

ri":"tel:+5213851866417"},"deliveryStatus":"DeliveryImpossible"}}}

Ejemplo de una respuesta en XML

HTTP/1.1 200 OK


Operación Entrada HTTP Response Code 200 OK Content-Type Headers Application/json

Application/xml (por defecto) Body Un elemento del tipo MessageDeliveryStatusType

indicado en el formato expresado en el Content-Type


Content-Type: application/xml;charset=ISO-8859-1

Content-Length: 554

Date: Fri, 23 Oct 2009 15:55:09 GMT

<v0:messageDeliveryStatus

xmlns:v0="http://www.telefonica.com/UNICA/mms_bodies/v0_1_1_LITMUS_LAT

AM_03102009">

<NS2:mmsMessageDeliveryStatus

xmlns:NS2="http://www.telefonica.com/UNICA/mms_types/v0_1_1_LITMUS_LAT

AM_03102009"

xmlns:NS1="http://www.telefonica.com/UNICA/mms_bodies/v0_1_1_LITMUS_LA

TAM_03102009">

<NS2:address>

<NS3:anyUri

xmlns:NS3="http://www.telefonica.com/UNICA_CommonTypes/v0_1">

tel:+5213851866417

</NS3:anyUri>

</NS2:address>

<NS2:deliveryStatus>DeliveryImpossible</NS2:deliveryStatus>

</NS2:mmsMessageDeliveryStatus>

</v0:messageDeliveryStatus>


4 NAMESPACES Los tipos de datos están definidos en el siguiente namespace: http://www.telefonica.com/UNICA/mms_types/v0_1_1_LITMUS_LATAM_03102009 Los elementos superiores utilizados en los cuerpos de las peticiones y repuestas REST están definidos en el siguiente namespace: http://www.telefonica.com/UNICA/MMS_bodies/v0_1_1_LITMUS_LATAM_03102009 Los tipos de datos comunes para todas las APIs están definidas en el siguiente namespace. http://www.telefonica.com/UNICA_CommonTypes/v0_1 Otros tipos de datos comunes adoptados de ParlayX están definidos en el siguiente namespace:

http://www.csapi.org/schema/parlayx/common/v3_1


5 DEFINICIÓN DE TIPOS DE DATOS En este capítulo se muestran las definiciones de los tipos de datos utilizados por esta API. Las siguientes consideraciones deben tenerse en cuenta:

• Las definiciones son mapeos directos a XML Schemas

• La definición de estos tipos de datos está basada en GSMA OneAPI [3] y ParlayX 3.1 [2]. En algunos casos, el tipo de dato corresponde directamente con un tipo de dato definido en ParlayX. Por lo tanto, en los esquemas proporcionados se importan los tipos de datos de ParlayX.

5.1 ESTRUCTURA DEL MessageType

Información para el envío de un MMS.

Los datos anteriores son los campos raíz del mensaje. Los contenidos MMS (texto plano y los datos multimedia adjuntos) se incluirán en el mensaje como subpartes, utilizando las guías de serialización descritas anteriormente.

En algunas ocasiones, los caracteres acentuados podrían no visualizarse correctamente en el terminal.

Nota: Se desaconseja el envío de MMS a más de una dirección simultáneamente.

5.2 ESTRUCTURA DEL MessageResultType

Respuesta de la operación REST SendMessage para consulta del estado de entrega.

5.3 ESTRUCTURA DEL MessageDeliveryStatusPollType

Utilizado como entrada para la consulta o recepción síncrona del estado de entrega de un MMS.

Parámetro Elemento tipo Opcional

Descripción

address uct:UserIdType [1..unbounded]

No Lista de direcciones a las cuáles se van a enviar los MMS. IdToken y valores de IP no son aceptadas.

subject xsd: string Sí El asunto del mensaje.

priority MessagePriorityType

Sí Prioridad del mensaje. Si no está presente, la red asignará una prioridad basada en políticas del operador. La validez de este parámetro depende del tipo de suscripción con el operador.

Parámetro Elemento tipo

Opcional

Descripción

mmsMessageResult

xsd: string

No Es un identificador correlado con el MMS enviado que se utiliza en una operación getMessageDeliveryStatus.

Parámetro Elemento tipo

Opcional

Descripción

messageIdenti

fier

xsd: string No Identificador relacionada con estado de entrega del MMS.


Debe tenerse en cuenta que el tipo de dato MessageDeliveryStatusPollType se utiliza en las operaciones GET y por lo tanto, debe pasarse en las peticiones en la URI de petición. De esta manera, no se utiliza XML ni JSON para la codificación de este tipo de datos.

5.4 ESTRUCTURA DEL MessageDeliveryStatusType

La estructura del MessageDeliveryStatusType está compuesta de los siguientes parámetros:

5.5 ENUMERACIÓN DEL MessagePriorityType

Lista de valores posibles de prioridad.

Note: Tomado de Parlay X MMS API [2]

5.6 ESTRUCTURA DEL DeliveryInformationType

Información de la entrega del MMS

Nota: Tomado de ParlayX MMS API [2]

5.7 ENUMERACIÓN DEL DeliveryStatusType

Lista de valores posible del estado de Entrega.

Nota: Tomados de ParlayX 3.1 [2]

alt xsd:string Sí Parámetro opcional que sirve para indicar que se realiza la consulta en formato JSON. (alt=JSON)


Descripción

mmsMessageD

eliveryStatus

DeliveryInformationType [0..unbounded]

Sí Describe las variaciones del estado de entrega del MMS. Valores posibles son: • DeliveredToNetwork • DeliveryUncertain • DeliveryImpossible • MessageWaiting • DeliveredToTerminal

Enumeración Descripción Default Prioridad por defecto

Low Prioridad baja Normal Prioridad normal High Prioridad alta


Descripción

address uct:UserIdType No Indica la dirección de destino con la que la notificación está relacionada.

deliveryStatus DeliveryStatusType

No Indica el resultado de la entrega para las direcciones de destino.

description xsd:string Sí Utilizado junto al estado de entrega (i.e. DeliveryImpossible) para proporcionar información adicional.


Nota: Actualmente este API no soporta informes de envío, por lo que siempre se recibirá el valor DeliveryNotificationNotSupported.

5.8 ENUMERACIÓN DEL AltType

Parámetro para solicitar una respuesta en formato JSON.

5.9 OPCIÓN UserIdType

Enumeración Descripción DeliveredToNetwork Entrega a la red con éxito

DeliveryUncertain Estado de entrega desconocido. (p. ej: por haber sido enviado a otra red)

DeliveryImpossible Entrega imposible, el mensaje no pudo ser entregado antes de expirar

MessageWaiting El mensaje está encolado para entrega. Este es un estado temporal, pendiente de transición a otro estado mencionado.

DeliveredToTerminal Entrega exitosa

DeliveryNotificationNotSupported

Imposible proveer la notificación de entrega. Se usa para indicar que la recepción de entrega para la dirección especificada en una operación SendMessage no está soportada.

Enumeración Descripción JSON El formato del contenido de la respuesta debe ser

JSON


Descripción

phoneNumber E164Type Sí Número de teléfono

anyUri xsd:anyURI Sí Cualquier URI

ipAddress IpAddressType Sí Dirección IP

alias AliasType Sí Alias

otherId OtherIdType Sí Cualquier otro tipo de identidad de usuario


6 LIBRERÍAS CLIENTE DE USO DE LAS APIS

6.1 CLIENTE JAVA

6.1.1 Directrices de Programación

De forma general, se define un interface principal para cada API, que define las operaciones REST de cliente permitidas para el correspondiente servicio. Mediante un mecanismo de factories se ofrecen implementaciones de estos interfaces, que funcionan como clientes REST. Estos clientes implementan las operaciones definidas para cada API utilizando un modelo de datos Java acorde con los tipos de datos definidos en las APIs.

El interface implementado por los clientes MMS es el siguiente:

• MMS API Client: es.tid.unica.rest.mms.MMSClient

La factory que debe ser usada para obtener una instancia de la clase cliente para MMS es la que sigue:

• MMS API Client Factory: es.tid.unica.rest.mms.MMSClientFactory

6.1.2 Ejemplo para el envío con el cliente MMS

El siguiente ejemplo muestra el uso del cliente para el uso de la API REST de MMS: • En primer lugar se realiza la construcción del objeto cliente (MMSClient), mediante el

uso de una factory (MMSClientFactory) • A continuación se configura el cliente con los datos necesarios, tanto para el

establecimiento de la conexión con el servidor (incluyendo el uso de un proxy, si es necesario, así como el endpoint en el que se encuentra el servicio al que se va a invocar), como para permitir la autenticación del cliente. Esto último supone especificar los elementos que forman las credenciales de seguridad que van a ser utilizadas.

• Una vez hecho todo lo anterior, ya es posible realizar el envío de un MMS, utilizando el método sendMessage. Dicho método toma como parámetros el mensaje en sí, construido utilizando las clases proporcionadas por la API, que siguen exactamente las especificaciones de tipos de datos explicados en las secciones anteriores, así como la codificación empleada.

• Una vez enviado el MMS se obtiene como respuesta un objeto, de la clase MMSResult, que contiene el resultado de la operación de envío, incluyendo la URI que podrá ser utilizada para consultar el delivery status de dicho SMS.

import es.tid.unica.rest.Encoding;

import es.tid.unica.rest.mms.MMSClient;

import es.tid.unica.rest.mms.MMSClientFactory;

import es.tid.unica.rest.mms.SendMessageResult;

import es.tid.unica.rest.mms.multipart.UnicaFilePart;

import es.tid.unica.rest.mms.multipart.UnicaPartBase;

import es.tid.unica.rest.mms.multipart.UnicaStringPart;

import es.tid.unica.types.common.E164Type;

import es.tid.unica.types.common.StringType;

import es.tid.unica.types.common.UserIdType;

import es.tid.unica.types.mms.MessageDeliveryStatusType;

import es.tid.unica.types.mms.MessagePriorityType;

import es.tid.unica.types.mms.MessageType;

. . .

// General configuration data


String base_uri = " https://200.39.21.12:8443/osg/UNICA-MMS-

REST";

String proxy_host = null; // No proxy is used

int proxy_port = 80;

// Security configuration data

String service_id = "0100114500";

String sp_id = "000137";

String sp_password = "123456";

String access_token = "czzwlpps";

String requestor_id = "5213907550006";

int requestor_type = 1;

//

String receipt_msisdn = "5213851866417";

String message_text = "This is the text to be sent";

File f_jpeg = new File("D:/…/Multimedia

content/Movistar_logo.jpg"); // A JPEG image to be sent.

try {

// Creating the client

MMSClient client =

MMSClientFactory.getInstance().createMMSClient(base_uri, proxy_host,

proxy_port);

// Initialize the client

client.setServiceId(service_id);

client.setSpId(sp_id);

client.setSpPassword(sp_password);

client.setAccessToken(access_token);

client.setRequestorId(requestor_id);

client.setRequestorType(requestor_type);

// Enable authentication

client.enableAuthentication(true);

//-----------------------------------------------

// Send an MMS.

//-----------------------------------------------

// 1. Build the message

MessageType mms = new MessageType();

// 1.1 Receipt address

UserIdType address = new UserIdType();

address.setPhoneNumber(new E164Type(receipt_msisdn));

mms.addAddress(address);

// 1.2 Subject (optional)

mms.setSubject(new StringType("The subject"));

// 1.3 Priority (optional)

MessagePriorityType priority = new MessagePriorityType();

priority.setHigh();

mms.setPriority(priority);

// 2. Add message parts

UnicaPartBase parts[] = new UnicaPartBase[2];

// 2.1 Text

parts[0] = new UnicaStringPart("message", message_text);

// 2.2 JPEG image

parts[1] = new UnicaFilePart(f_jpeg.getName(), f_jpeg,

UnicaFilePart.IMAGE_JPEG);

// 3. Send the message.


SendMessageResult result = client.sendMessage(mms, parts,

Encoding.APPLICATION_XML);

System.out.println("The result of the sendMessage opeation

is " + result);

//-----------------------------------------------

//-----------------------------------------------

// Retrieve the delivery status of the sent MMS.

//-----------------------------------------------

MessageDeliveryStatusType status =

client.getMessageDeliveryStatus(result.getLocationHeader().toString(),

null);

System.out.println("The result of the

getMessageDeliveryStatus opeation is " + status);

//-----------------------------------------------

} catch (Exception e) {

e.printStackTrace();

}

6.1.3 Paquetes del Cliente

La librería Java de cliente MMS está formada por los siguientes paquetes:

6.1.4 Prerrequisitos

Para el correcto funcionamiento de la librería de cliente de Java de SMS es necesario tener instalada la versión 1.5 o superior del JRE (Java Runtime Environment) o JDK (Java Development Kit).

También es necesario utilizar las librerías contenidas en los archivos .jar situados en el directorio lib de la distribución del cliente Java.

6.2 CLIENTE C#


Se define una clase factory para cada API actuando como creador de clientes REST. A partir de una instancia única de la factory se puede obtener un cliente para el API al que pertenece, poblado con más o menos datos iniciales dependiendo de la operación de creación utilizada. El cliente obtenido, por flexibilidad a la hora de proveer diferentes implementaciones, se ofrece en forma de interfaz del lenguaje C#.

Enumeración Descripción es.tid.unica.rest.mms Paquete que contiene las clases principales

para el cliente MMS REST API. es.tid.unica.types.common Paquete que contiene los tipos de datos

principales para los mensajes y los parámetros utilizados por las APIs.

es.tid.unica.types.parlayx.common

Este paquete contiene los tipos de datos básicos de ParlayX, que pueden ser utilizados en las APIs

es.tid.unica.types.mms Paquete que contiene los tipos de datos específicos de la API de MMS


La interfaz obtenida a partir del factory se comportará como un cliente REST. Estos clientes implementan las operaciones definidas para cada API utilizando un modelo de datos C# acorde con los tipos de datos definidos en las APIs.

La factory e interfaz del cliente MMS para la API REST son los siguientes:

• MMS Client Factory: es.tid.unica.rest.mms.MMSClientFactory • MMS Client Interface API: es.tid.unica.rest.mms.IMMSClient

Nota: Para garantizar el correcto funcionamiento de esta librería, en el CLASSPATH debe ir siempre la librería "unica_rest_api_common_client_lib_v0_1.jar" antes que la "commons-httpclient-3.1.jar".

Ejemplo: java -classpath […]: <jars_path>/unica_rest_api_common_client_lib_v0_1.jar:[…]:

<jars_path>/commons-httpclient-3.1.jar:[…]

6.2.2 Ejemplo para el envío con el cliente MMS

El siguiente ejemplo muestra el uso del cliente para el uso de la API REST de MMS:

try

{

//1.- create a client instance from SMS factory

IMMSClient mmsClient =

MMSClientFactory.GetInstance().

CreateMMSClient(baseUri, proxyHost, proxyPort);

//2.- set authentication credentials

mmsClient.Credentials.ServiceId = "0100105500";

mmsClient.Credentials.SpId = "000025";

mmsClient.Credentials.SpPassword = "123456";

mmsClient.Credentials.RequestorId = "5213907550010";

mmsClient.Credentials.RequestorType = 1;

mmsClient.Credentials.AccessToken = "gUi63vho";

//3.- Build a MMS message

MessageType mms = new MessageType();

//4.- Create and add addresses

UserIdType firstAddress = new UserIdType();

firstAddress.PhoneNumber = new E164Type("5213851866417");

UserIdType secondAddress = new UserIdType();

secondAddress.PhoneNumber = new E164Type("5213913022264");

mms.AddAddress(firstAddress);

mms.AddAddress(secondAddress);

//5.- Create multimedia contents

UnicaStringPart text = new UnicaStringPart(

"text",

"This is the text content of the MMS");

UnicaFilePart image_gif = new UnicaFilePart(

"Movistar_logo.gif",

new FileInfo("C:\\Movistar_logo.gif"),

UnicaPartBase.IMAGE_GIF);


UnicaPartBase[] mmsContentParts = new UnicaPartBase[] { text,

image_gif };

//6.- Send MMS

SendMessageResult result =

mmsClient.SendMessage(mms, mmsContentParts,

Encoding.APPLICATION_URL_ENCODED);

//7.- use result as you need

Console.WriteLine("Send MMS Result produced: {0}",

result.MessageResult.MmsMessageResult.ToString());

Console.WriteLine("HTTP Location header received in response:

{0}", result.LocationHeader.ToString());

return result.LocationHeader.ToString();

}

catch (Exception ex)

{

Console.Error.WriteLine(ex.Message);

throw;

}


Se describen los paquetes

6.2.4 Prerrequisitos

Para el correcto funcionamiento de las APIs C# son necesarios lo siguientes prerrequisitos:

• Sistema Operativo Windows XP Service Pack 2 (o superior) o Windows Vista

• Microsoft .NET Framework 3.5, disponible para descarga gratuita en http://www.microsoft.com/downloads

Esta librería no ha sido diseñada para otros entornos como Mono o Portable.NET.

6.3 CLIENTE PHP

6.3.1 Dependencias

• PHP ≥ 5.2.6

• PHP5-CURL ≥ 5.2.6

• CURL ≥ 7.18.2

Enumeración Descripción es.tid.unica.rest.mms Paquete que contiene las clases principales

para el cliente MMS REST API. es.tid.unica.types.common Paquete que contiene los tipos de datos

principales para los mensajes y los parámetros utilizados por las APIs.

es.tid.unica.types.parlayx.common

Este paquete contiene los tipos de datos básicos de ParlayX, que pueden ser utilizados en las APIs

es.tid.unica.types.mms Paquete que contiene los tipos de datos específicos de la API de MMS



Se define una clase para cada API actuando como un cliente REST. Estos clientes implementan las operaciones definidas para cada API utilizando como referencia los tipos de datos definidos en las APIs.

Las clases del cliente MMS para la API REST son las que siguen (una clase para cada tipo de codificación):

• mmsRESTlibraryXML.php • mmsRESTlibraryJSON.php • mmsRESTlibraryURLEnc.php

6.3.3 Esta librería se ha probado en los siguientes sistemas operativos: CentOs 5, Fedora 11, Ubuntu Jaunty, Ubuntu Karmic, Debian Lenny, Windows 7 y Windows XP.Ejemplo para el envío con el cliente MMS

El siguiente ejemplo muestra el uso del cliente para el uso de la API REST de MMS: <?php

// Select only one of this

include_once "../src/mmsRESTlibraryXML.php";

$mmsClient = new

mmsRESTclient($spId,$serviceId,$spPassword,$token,$requestor_id,$apien

dpoint);

//Set up mandatory parameters

$address["phoneNumber"]="5213851866417";

//Adding Attchaments

if (!$mmsClient-

>AddAttachment('../../Multimedia/Movistar.txt','','8bit','text/plain')

) echo "\nThere was an error adding File to MMS";

if (!$mmsClient-

>AddAttachment('../../Multimedia/Movistar.jpg','','base64','image/pjpe

g')) echo "\nThere was an error adding File to MMS";

//Send message

$result = $mmsClient->sendMMS($address);

//Checking response

$protocol=explode (":",strtolower($result));

if ($protocol[0] == 'http' || $protocol[0] == 'https'){

//Getting Delivery Status

$deliveryStatus = $mmsClient-

>getMessageDeliveryStatus($result);

echo $deliveryStatus;

}

else {

//An error ocurred

echo $result;

}

?>


Se describen los paquetes

Enumeración Descripción


mmsRESTlibraryXML.php Paquete que contiene la clase principal para el cliente MMS REST API con codificación XML.

mmsRESTlibraryJSON.php Paquete que contiene la clase principal para el cliente MMS REST API con codificación JSON.

mmsRESTlibraryURLEnc.php

Paquete que contiene la clase principal para el cliente MMS REST API con codificación URL encode.


7 DETALLE DE LAS DESCRIPCIONES DE ERROR Las operaciones descritas en esta guía pueden devolver una serie de códigos de error HTTP, como se explica a continuación.

En caso de producirse algún error relacionado con:

- spId o serviceId no válidos

- spPassword no válido

- La aplicación no tiene permisos para utilizar el API

- Parámetros no válidos

- Violación de los SLA

se responderá con un código de estado HTTP del tipo 4XX/5XX.

Sin embargo, si de produce un error relacionado con:

- token no válido

- El MSISDN no tiene permisos para utilizar el API

se responderá con un código de estado HTTP 201, pero al consultar el estado del envío se obtendrá el valor DeliveryImpossible.


A CONSIDERACIONES GENERALES

En esta sección se describen elementos necesarios para el normal funcionamiento de la API REST MMS:

• Métodos HTTP: que constituyen las operaciones RESTful, de acuerdo con los principios REST.

• Representaciones comunes.

A.1 Métodos HTTP Las siguientes descripciones se han extraído de la RFC de HTTP 1.1.

A.1.1 POST

El método POST se utiliza para solicitar que el servidor de origen acepte la entidad contenida en la petición como un nuevo recurso identificado por la URI de la petición en la Request-Line. POST está diseñado para permitir un método uniforme que cubra las siguientes funciones:

• Anotación de recursos existentes.

• Postear un mensaje en un boletín, grupo de noticias, lista de correo, o grupo similar de artículos.

• Proveer un bloque de datos, como el resultado del envío de un formulario, para que sea procesado.

• Extender una base de datos a través del añadido de una operación.

La actual funcionalidad desarrollada por el método POST está determinada por el servidor y es usualmente dependiente de la Request-URI. La entidad posteada está subordinada a esa URI de la misma manera que el archivo está subordinado al directorio que lo contiene, un artículo de noticias está subordinado a un grupo de noticias al que está posteado, como un registro está subordinado a una base de datos.

A.1.2 GET

El método GET intenta extraer cualquier información (en la forma de una entidad) identificada por una Request-URI. Si la Request-URI se refiere a un proceso que genera datos, es un dato producido que debe devolverse como la entidad en la respuesta y no el texto origen del proceso, a no ser que el texto sea la salida del proceso.

A.1.3 PUT

El método PUT solicita que la entidad contenida sea almacenada bajo la Request-URI proporcionada. Si la Request-URI se refiere a un recurso existente, la entidad contenida


debe ser considerada como una versión modificada del recurso residente en el servidor. Si la Request-URI no apunta a un recurso existente, y la URI es capaz de ser definida como un nuevo recurso por el agente solicitante, el servidor de origen puede crear el recurso con esa URI.

A.1.4 DELETE

El método Delete solicita que el servidor de origen borre el recurso identificado con la Request-URI. Este método puede ser reescrito por intervención humana (u otros métodos) en el servidor de origen. El cliente no puede garantizar que la operación haya sido llevada a término, incluso si el código de estado devuelto desde el origen indica que la acción ha sido completada con éxito. Sin embargo, el servidor no debe indicar una respuesta satisfactoria a no ser que, en el momento en que la respuesta es entregada, intente borrar el recurso o moverlo a una localización inaccesible.

A.2 REPRESENTACIONES COMUNES

A.2.1 JSON

Las peticiones POST pueden incluir datos en formato JSON. Las respuestas deben incluir el cuerpo en formato JSON, si corresponden a peticiones POST incluidas en formato JSON o si corresponden a peticiones GET incluidas con el parámetro ‘alt=json’. En estos casos, la cabecera Content-Type:Application/json debe estar presente en la respuesta.

A.2.2 XML

Las peticiones POST pueden incluir datos en formato XML. En estos casos, se utiliza un cuerpo application/xml. Este formato XML debe cumplir con las especificaciones de XML Schema. Las respuestas deben incluir un cuerpo del XML si la correspondiente petición POST incluye datos en formato XML o si la correspondiente petición GET no incluía el parámetro ‘alt=json’. En estos casos, la cabecera Content-Type: Application/xml debe estar presente en la respuesta.


B REFERENCIAS

[1] 3GPP TS 29.199-1: "Open Service Access (OSA); Parlay X Web Services; Part 1: Common [2] 3GPP TS 29.199-5: "Open Service Access (OSA); Parlay X Web Services; Part 5: Multimedia Messaging". [3] GSMA OneAPI, http://gsma.securespsite.com/access/default.aspx [4] RFC 2616: “Hypertext Transfer Protocol -- HTTP/1.1” [5] W3C Recommendation (26 June 2007): "Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts”, https://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626/#_http_binding_default_rule_method [6] W3C Recommendation (2 May 2001): "XML Schema Part 2: Datatypes", http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/.

Download - MMS REST API Developers Guide

Top Related