PUT

You update using the PUT call with a resource as the payload.
lac31
You update using the PUT call with a resource as the payload. In most cases, you will want to refer to a specific object using the URI returned in the 
@metadata
 section. You can test your updates using the REST Lab. You can verify proper operation (SQL and logic) using the log.
In this article:
2
Batched Update
You can reduce latency by retrieving large amounts of data in a single retrieval request. Similarly, you can send in multiple rows on updates. You can update by sending the following resources:
You can send back the objects that have changed in the PUT.
Update by Sending a Single Resource
The most basic update is to update by sending in a single resource. In database terms, this might represent multiple rows, such as an Order and its Lineitems. You specify the URL as the top-level resource.
For example, you might define a resource of Customers, Orders, and Lineitems. To update an order, you send the order and any updated Lineitems. In many cases, the end user can update only one Lineitem of several. For example, to update Order 1, you specify the URL as:
<API Project URL>/Customer.Orders/1
Updates are incremental. You only need to send the altered data. You can send unaltered data (for example, the unchanged Lineitems), but the data is not updated.
Update by Sending Homogeneous Resources
You can update by sending in an array of resources, such as a list of Orders with their contained LineItems. Each of the contained rows must conform to the type denoted in the URL. They can include contained items (for example, Lineitems for Customer.Orders). This update operates like the update by sending in a single resource, except you send in an array of resources. For example, to update a list of orders, specify the URL as:
<API Project URL>/Customer.Orders
Update by Sending Heterogeneous Resources
For optimal client operation (though a less common REST idiom), you can update by sending the resource a set of unrelated rows for updates with no requirement that they be the same type or defined within the containing resource. This update supports the paradigm where an application allows end users to retrieve multiple rows of multiple types, make extensive edits (including to multiple types), and send in the changes as a single request.
For example, an end user alters Order 1, changes a Lineitem for Order 2, and adds a Lineitem for Order 3. Specify this as a PUT directed to the API project URL.
Each row must contain a 
@metadata
 section. 
CA Live API Creator
 uses the information in this section to find the appropriate logic by determining the type of row. The 
@metadata
 section can be an assortment of inserts, updates, and deletes. You specify the verb by way of the 
@metadata
 
verb
 property, for example:
{
"@metadata": {
"href": "http://rest.ablserver.com/v1/product/27",
"entity": "product",
"verb": "UPDATE",
"checksum": "9e0724221638aa5bcd35cff70826115ce"
},
For more information about 
projURL
, see The API Project URL.
Refresh Information
Updates can have computational side effects. The side effect can be both on rows updated or related data. For example, paying an order would reduce the customers' balance. Good UI design entails these results are shown to the end user. In many cases, this requires a subsequent "fetch for refresh". This requirement is inefficient, and in some cases not possible when the refreshed data has a system-generated primary key.
 
CA Live API Creator
 sends back the update response that contains all the updated rows. These are coerced into the types designated in the updating resource.
 For more information about how to get a summary of the rules that were executed in a transaction, see Transaction Summary.
Optimistic Locking
You must supply the optimistic locking value on update. This is typically automatic, since it is returned to you on retrieval. In rare circumstances, you can override this check by specifying the 
checksum
 value. If you do not want optimistic locking, you can specify the 
checksum
 value as override. For example, the following is the resulting URL:
http://localhost:8080/APIServer/rest/el-local/demo/v1/demo:customer/New%20Customer?
checksum=override
To prevent lost updates, do not bypass integrity checks by specifying the 
checksum
 value.
Relationships Examples
The following are examples of updating using the PUT call.
Example: By Containment
This example uses the OneCustomer resource from Logic Demo, which contains a Customer, Order, Lineitems, and Product (a parent subresource). You create an order using the following nodal URL:
http://.../myserver/rest/abl/demo/demo1/OneCustomer.Orders
The following response is expected:
{
"customer_name":"Alpha and Sons",
"Paid":false,
"Lineitems": [
{
"product_number":1,
"qty_ordered":3
}
]
}
The Lineitem is not attached to the order, since this was implicit in the containment.
Example: By Foreign Key
Using the same example as By Containment, attach the Lineitem to the Product using a foreign key.
Example: By Sub Resource
Using the same example as By Containment, you can attach the Lineitem to the Product as shown in the following code snippet. Provide the foreign key a parent subresource:
{
"customer_name":"Alpha and Sons",
"Paid":false,
"Lineitems": [
{
"product_number":1,
"qty_ordered":3,
"Product": {
"@metadata": {
"href": "http://localhost:8080/KahunaService/rest/abl/demo/demo1/OneCustomer.Orders.Lineitems.Product/1",
"checksum": "6e71fde53ade7203d8dc2476c49af241"
},
"product_number": 1,
"name": "Hammer",
"price": 10
}
}
]
}