Update an existing record in the database and notify subscribed sockets that it has changed.
PATCH /:model/:id
This updates the record in the model which matches the id parameter and responds with the newly updated record as a JSON dictionary. If a validation error occurred, a JSON response with the invalid attributes and a 400
status code will be returned instead. If no model instance exists matching the specified id, a 404
is returned.
Attributes to change should be sent in the HTTP body as form-encoded values or JSON.
Parameter | Type | Details |
---|---|---|
model | The identity of the containing model. e.g. 'product' (in PATCH /product/5 ) |
|
id | The primary key value of the record to update. e.g. '5' (in PATCH /product/5 ) |
|
* | For PATCH (RESTful) requests, pass in body parameters with the same name as the attributes defined on your model to set those values on the desired record. For GET (shortcut) requests, add the parameters to the query string. |
Change Applejack's hobby to "kickin":
PATCH /user/47
{
"hobby": "kickin"
}
{
"hobby": "kickin",
"id": 47,
"name": "Applejack",
"createdAt": 1485462079725,
"updatedAt": 1485476060873
}
If you have WebSockets enabled for your app, then every client subscribed to the updated record will receive a notification where the event name is that of the model identity (e.g. user
), and the data “payload” has the following format:
verb: 'updated',
id: <the record primary key>,
data: <a dictionary of changes made to the record>,
previous: <the record prior to the update>
For instance, continuing the example above, all clients subscribed to User
#47 (except for the client making the request) would receive the following message:
{
id: 47,
verb: 'updated',
data: {
id: 47,
hobby: 'kickin'
updatedAt: 1485476060873
},
previous: {
hobby: 'pickin',
id: 47,
name: 'Applejack',
createdAt: 1485462079725,
updatedAt: 1485462079725
}
}
If the update changed any links to other records, there might be some additional notifications:
If we were reassigning user #47 to store #25, we'd update store
, which represents the “one” side of a one-to-many association. For instance:
PATCH /user/47
{
"store": 25
}
Clients subscribed to the new store (25) would receive an addedTo
notification, and a removedFrom
notification would be sent to any clients subscribed to the old store. See the add blueprint reference and the remove blueprint reference for more info about those notifications.
- This action can be used to replace an entire collection association (for example, to replace a user’s list of friends), achieving the same result as the
replace
blueprint action. To modify items in a collection individually, use the add or remove actions.- In previous Sails versions, this action was bound to the
PUT /:model/:id
route.