How to send a request in Data Exchange API

Ensure the Data Exchange API is integrated (follow Data Exchange API integration) and configured (follow How to configure Data Exchange API) as described in the guides.

Note, by default the API GET request returns up to 20 records.

Note, so far when you combine multiple filters in a single request, the system applies an “AND” condition to the retrieved results.

Note if a current endpoint is not configured in spy_dynamic_entity_configuration and it’s not found you’ll get the following response:

[
    {
        "message": "Not found",
        "status": 404,
        "code": "007"
    }
]

Note that all fields included in the request payload are marked as isCreatable: true in the configuration. Therefore, the API will create a new record with all the provided fields. However, if any of the provided fields are configured as isCreatable: false it will result in an error.

Let’s configure isCreatable: false for iso3_code and send the same request. You will receive the following error response because a non-creatable field iso3_code is provided:

[
  {
    "message": "Modification of immutable field `iso3_code` is prohibited.",
    "status": 400,
    "code": "1304"
  }
]

It is important to consider that certain database-specific configurations may result in issues independent of entity configurations.

For instance, in the case of MariaDB, it is not possible to set the ID value for an auto-incremented field. Additionally, for the iso2_code field in the spy_country table, it must have a unique value. Therefore, before creating a new record, it is necessary to verify that you do not pass a duplicated value for this field. Otherwise, you will receive the following response:

[
    {
        "message": "Failed to persist the data. Please verify the provided data and try again. Entry is duplicated.",
        "status": 400,
        "code": "1309"
    }
]

This response is caused by a caught Propel exception, specifically an integrity constraint violation (Integrity constraint violation: 1062 Duplicate entry 'WA' for key 'spy_country-iso2_code').

It is also possible to send a PATCH request for a specific ID instead of a collection, use the following request:

PATCH /dynamic-entity/country/1 HTTP/1.1
Host: glue-backend.mysprykershop.com
Content-Type: application/json
Accept: application/json
Authorization: Bearer {your_token}
Content-Length: 143
{
    "data": {
            "iso2_code": "WB",
            "iso3_code": "WWB",
            "name": "FOO"
        }
}

Note that all fields included in the request payload are marked as isEditable: true in the configuration. Therefore, the API will update the found record with all the provided fields. However, if any of the provided fields are configured as isEditable: false it will result in an error.

Let’s configure isEditable: false for iso3_code and send the same request.

You will receive the following error response because a non-editable field iso3_code is provided:

[
  {
    "message": "Modification of immutable field `iso3_code` is prohibited.",
    "status": 400,
    "code": "1304"
  }
]

If id_country is not provided you will get the following response:

[
  {
    "message": "Incomplete Request - missing identifier.",
    "status": 400,
    "code": "1310"
  }
]

If id_country is not found you will get the following response:

[
  {
    "message": "The entity could not be found in the database.",
    "status": 404,
    "code": "1303"
  }
]

Similarly to the POST request, it is important to consider database-specific configurations when sending a PATCH request.

It is also possible to send a PUT request for a specific ID instead of a collection using the following request:

PUT /dynamic-entity/country/1 HTTP/1.1
Host: glue-backend.mysprykershop.com
Content-Type: application/json
Accept: application/json
Authorization: Bearer {your_token}
Content-Length: 143
{
    "data": {
            "iso2_code": "WB",
            "iso3_code": "WWB",
            "name": "FOO"
        }
}

When using PUT requests, it’s important to consider that the same rules and configurations apply as with PATCH and POST requests. This means that the isEditable attribute determines whether existing items can be modified during a PUT request. Additionally, the isCreatable attribute is used for non-existing items that are created automatically according to the PUT request RFC.

In technical terms, the PUT request follows the same guidelines as PATCH and POST requests in relation to the definition and database-specific configurations. The isEditable attribute governs the update capability of existing items during a PUT request, ensuring that only editable fields can be modified. Similarly, the isCreatable attribute pertains to non-existing items and governs their automatic creation as part of the PUT request process, adhering to the standards outlined in the PUT request RFC. It’s crucial to adhere to these rules and configurations to ensure accurate and consistent data manipulation during PUT operations.