Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Issues/Decisions

Introduction

There are few inconsistencies and missing features found within the CPS core APIs. This proposal aims to discuss these problems and suggest appropriate solutions for the same. The following list of APIs are found to be impacted by the findings:

  • Get a node
  • Update node leaves
  • Replace a node with descendants

Detailed Analysis

Get a Node

Problem Description:

When a list is fetched using Get a node API then instead of returning a list containing n-number of list nodes, the API returns n-lists containing one data node in each list.

For example: if there is a list named "Items" containing 10 items named Item 1, Item 2, ......, Item 10. Then when fetching this list using get a node API a total of 10 individual lists are returned where each list contains one Item, i.e. List 1→Item 1, List 2→ Item 2, ......., List 10→ Item 10.

Data Originally Stored
{
  "book-store:bookstore": {
    "bookstore-name": "Easons",
    "categories": [
      {
        "code": "1",
        "name": "Children",
        "books": [
          {
            "title": "Matilda",
            "lang": "English",
            "price": 20
          },
          {
            "title": "The Gruffalo",
            "lang": "English",
            "price": 15
          }
        ]
      }
    ]
  }
}

Response when querying the list directly.

Current output
[
  {
    "books": {
      "title": "Matilda",
      "lang": "English",
      "price": 20
    }
  },
  {
    "books": {
      "title": "The Gruffalo",
      "lang": "English",
      "price": 15
    }
  }
]


Expected Result
[
  {
    "books": [
      {
        "title": "Matilda",
        "lang": "English",
        "price": 20
      },
      {
        "title": "The Gruffalo",
        "lang": "English",
        "price": 15
      }
    ]
  }
]
This behavior extends to list items stored under root node as well. So, this case needs to be taken into consideration as well

Update node leaves

Problem Description

When updating any data node, it's parent node xpath is provided as part of the update request. And the JSON payload contains the data of child node to be updated.

But if the JSON data of the parent node is provided as part of this payload, then instead of failing, the request is successfully executed with partial update Where only the child data node is updated and the parent data node is not updated.




Notes


Original JSON data:
{
  "code": 1,
  "name": "Children",
  "books": [
    {
      "title": "Matilda",
      "lang": "English",
      "authors": ["Roald Dahl"],
      "editions": [1988, 2000],
      "price": 20
    }
  ]
}
JSON with updates
{
  "code": 1,
  "name": "Kids",
  "books": [
    {
      "title": "Matilda",
      "editions": 
		[1988, 2000, 2024],
      "price": 25
    }
  ]
}
JSON data after update
{
    "code": "1",
    "name": "Children",
    "books": [
      {
	 	"title": "Matilda",
        "lang": "English",
        "authors": ["Roald Dahl"],
        "editions": 
			[1988, 2000, 2024],
		"price": 25
       }
    ]
  }
  • It can be seen that the leaf data belonging to parent node i.e. code=1 is sent as part of JSON body. Where name is changed from Children to Kids
  • And the fields editions and price, of child node, i.e. title=Matilda are modified.
  • But after the request is executed only the child node is updated.
  • The expected behavior should be to throw an exception as the Update a node API requires parent node xpath to update any child data. Which in this case should be "/bookstore" because the request is also updating the node with key "code=1"
  • This situation can mainly occur due to user error, where user provides updated parent data along with parent node xpath as part of the request.

Problem Description 2

Update operation can only be done on one node at a time and when trying to update parent child in one request, then only the parent node is updated.





Original JSON data
{
  "categories": {
    "code": "1",
    "name": "Children",
    "books": [
      {
	 	"title": "Matilda",
        "lang": "English",
        "price": 200,
        "authors":["Roald Dahl"],
        "editions": [1988,2000]
      }
    ]
  }
}
JSON to be updated
{
  "categories": {
    "code": 1,
    "name": "Kids",
    "books": [
      {
        "title": "Matilda",
	 	"price": 20,
		"editions": 
		[1988, 2000, 2022]
      }
    ]
  }
}
Updated JSON data
{
  "categories": {
    "code": "1",
    "name": "Kids",
    "books": [
      {
        "title": "Matilda", 
     	"lang": "English",
        "price": 200,
        "authors": ["Roald Dahl"],
		"editions": [1988,2000]        }
    ]
  }
}
  • The request is executed successfully but only a partial update takes place in the database.
  • So, either the API should reject any request containing multiple nodes or support updating multiple nodes at once.

Replace a node with descendants

Problem Description

If a replace operation is performed on a list, where a new list item is also added to the list, then it results in a 200-response code, with a partial replace operation.




Notes
Original JSON data
[
  {
    "book-store:books": {
	  "title": "Matilda",
      "lang": "English",
      "price": 20,
      "authors": ["Roald Dahl"],
      "editions": [1988,2000]
    }
  }
]
Data to replace
{
  "books": [
    {
      "title": "Matilda",
      "lang": "English",
      "authors": ["Roald Dahl"],
      "editions": [2024]
    },
    {
      "title": "The Gruffalo",
      "lang": "English",
      "authors": ["Julia Donaldson"],
      "editions": [1999],
      "price": 15
    }
  ]
}
Result after Replace operation
[
  {
    "book-store:books": {
	  "title": "Matilda",
      "lang": "English",
      "authors": ["Roald Dahl"],
      "editions": [2024]
    }
  }
]
  • This is a user error as request here is itself wrong, because it tries to add a new list element.
  • CPS provides a separate endpoint to Add a list element
  • So, such a scenario should be handled by the API instead of returning a successful response.
  • No labels