API ReferenceSDK & PluginsFAQsContact Us

Solicitudes y respuestas

Algunos métodos requieren datos para la entrada; otros no tienen salida.

Si bien la mayoría de los métodos se llaman a través de GET, algunos métodos de escritura obtienen datos de solicitud adicionales enviados a través de POST.

Todos los métodos devuelven un documento de respuesta, que indica el estado de la operación (ya sea Éxito o Error) y, opcionalmente, proporciona resultados y / o detalles relacionados con la acción especificada.

Datos de solicitud adicionales a través de POST

Como hemos visto, todos los métodos se llaman a través de HTTP. Algunos a través de GET y otros a través de POST.

Todas las llamadas siempre toman los parámetros Action, Timestamp, UserID, Version y Signature.
A menudo, se agregan parámetros adicionales. P.ej, GetProducts toma parámetros adicionales, como un parámetro Search.

Pero a veces, los datos que se deben proporcionar son más de los que se pueden transportar en los parámetros de la solicitud. En esos casos, se envían datos adicionales al servidor mediante una solicitud POST. Los datos deben estar en formato XML (incluso si el parámetro Formato está establecido en 'JSON'). Todos los datos (incluidos los nombres y valores de los parámetros) deben estar codificados en UTF8 (lo que debe indicarse en el preámbulo XML) y cargarse como aplicación de tipo MIME / x-www-form-urlencoded.

Los siguientes pueden ser datos adicionales enviados al método ProductUpdate:

<?xml version="1.0" encoding="UTF-8" ?>
<Request>
  <Product>
    <SellerSku>SKU-AAAA</SellerSku>
    <Price>10.0</Price>
    <SaleStartDate>2015-07-01T11:11:11+0000</SaleStartDate>
    <SaleEndDate>2015-07-01T11:11:11+0000</SaleEndDate>
    <SalePrice>8.0</SalePrice>
  </Product>
  <Product>
    <SellerSku>SKU-BBBB</SellerSku>
    <Price>32.5</Price>
  </Product>
</Request>

📘

GET o POST

El uso de GET o POST es específico del método al que está llamando y se indica en esta documentación. Incluso si no es necesario cargar datos adicionales para una solicitud, debe usar POST si ese es el comando HTTP especificado para el método.

📘

Limitaciones del tamaño de la solicitud POST

Según la configuración del servidor web estándar de SC, el tamaño máximo del cuerpo de la solicitud POST es 128MB.

Resultados sin datos

Algunos métodos devuelven documentos XML largos. Por ejemplo, GetProducts devolverá un documento XML muy largo, con una lista de cada producto. La sintaxis de estas respuestas se explica en detalle en la página de referencia del método.

Pero varios métodos no devuelven datos. En esos casos, todavía se devuelve una respuesta. A esto lo llamamos SuccessResponse. Dependiendo del parámetro Format que se pasó, puede estar en JSON o XML (hay pestañas a continuación para ver cualquiera de las dos):

<?xml version="1.0" encoding="UTF-8"?>
<SuccessResponse>
  <Head>
    <RequestId>13e55362-3cc4-446b-b3db-c1df0900ae9e</RequestId>
    <RequestAction>PriceFeed</RequestAction>
    <ResponseType></ResponseType>
    <Timestamp>2015-07-01T11:11:11+0000</Timestamp>
  </Head>
  <Body/>
</SuccessResponse>

{
  "SuccessResponse": {
    "Head": {
      "RequestId": "13e55362-3cc4-446b-b3db-c1df0900ae9e",
      "RequestAction": "PriceFeed",
      "ResponseType": "",
      "Timestamp": "2015-07-01T11:11:11+0000"
    },
    "Body": ""
  }
}

Los campos de la sección son siempre los mismos, independientemente de si un método devuelve datos en la sección Body o no. El significado de los datos en una SuccessResponse es el siguiente:

NombreTipoDescripción
RequestIdUUIDUna identificación única de esta solicitud. Usado por Feeds.
RequestActionStringEl nombre del método que se llamó (es decir, el parámetro Action de la solicitud).
ResponseTypeStringEl tipo de respuesta contenido en el cuerpo, o vacío si no hay ninguno.
TimestampDateTimeHora de envío de la solicitud, en formato ISO 8601.
BodySubsectionHora a la que se envió la solicitud, en formato ISO 8601.

Del mismo modo, hay un ErrorResponse. También tiene una sección, que a menudo está vacía, pero se puede utilizar para proporcionar información adicional al error. A continuación, se muestra un mensaje de error de ejemplo que tiene un cuerpo (Body):

<?xml version="1.0" encoding="UTF-8"?>
<ErrorResponse>
  <Head>
    <RequestAction>Price</RequestAction>
    <ErrorType>Sender</ErrorType>
    <ErrorCode>1000</ErrorCode>
    <ErrorMessage>Format Error Detected</ErrorMessage>
  </Head>
  <Body>
    <ErrorDetail>
      <Field>StandardPrice</Field>
      <Message>Field must contain a positive number with a dot as decimal
        separator and 2 decimals (e.g. 120.00)
      </Message>
      <Value>10.0x</Value>
      <SellerSku>Example Seller SKU</SellerSku>
    </ErrorDetail>
  </Body>
</ErrorResponse>

Response:
{
  "ErrorResponse": {
    "Head": {
      "RequestAction": "ProductUpdate",
      "ErrorType": "Platform",
      "ErrorCode": "1000",
      "ErrorMessage": "Could not save product: 0, A exact match of the document is being processed"
    },
    "Body": ""
  }
}

Aquí también, los campos tienen un significado fijo en todos los métodos:

NombreTipoDescripción
RequestActionStringEl método que provocó el error.
ErrorTypeStringEl origen del error (Sender o Platform).
ErrorCodeIntegerEl código de error interno (see Errores).
ErrorMessageStringMensaje de error legible por humanos.
ErrorDetailSubsectionLa respuesta de error puede contener estas subsecciones en su cuerpo (body). Contiene campos específicos del error. Son provistos a lo sumo 50 ErrorDetails.