I have an API controller for an entity called Order which has as an attribute called Status which can take the following values: Pending, Cancelled, Production, Delivered.
I was wondering which would be the proper approach for updating such attribute.
Should i have PUT endpoints for each value of Status to update the attribute with only the id or should I have the typical REST PUT endpoint and just update the value according to a request body containing the object id and it's new Status value?
PS: I'm already managing the values internally as an enum so I don't have to worry about faulty input
A PUT operation updates some resource. If you are updating a 'status resource' to have a value, or if you are updating an 'order resource' to have a different status, I would expect a PUT or PATCH request on a resource like /order/123 or /order/123/status.
Having a endpoint/resource per status makes no sense, because you are updating an order (with PUT), you are not updating the 'Pending status resource'.
Related
https://rally1.rallydev.com/slm/webservice/v2.0/typedefinition/<defect_id>/Attributes
After hitting the specified url we get the fields for the specified defect id but in order to fetch the allowed values for dropdown fields we have to hit another api.
Is there any other way through which we can get all the fields with the allowed values instead of the reference to the allowed values in a single api call?
Unfortunately with the introduction of WSAPI version 2.0, the ability to load sub collections of data within the initial request was removed. This was done in order to improve performance as it was previously possible to request too large a set of data and have a significant impact on the performance of the system.
So the only way to fetch the lists of allowed values for fields is to loop through the list of defect attributes, grab the necessary endpoint url from the _ref value and load it from there.
It could be worth saving the references to these attribute IDs as they shouldn't change as long as the fields aren't removed from the object model.
Deleting an item from a collection, which has a status field, through the UI or API results in the item being soft deleted. However, in this one particular instance, we want to remove it from the database entirely.
If not possible, can it safely be done through the database by just deleting it from the table carrying the name of the collection? Any side-effects when doing it this way?
Found the answer on this page https://v8.docs.directus.io/guides/status.html#soft-delete:
When deleting an item, the API does the following:
Check if the collection has a status field
Check if the delta data has the status field (meaning the status was changed)
Check if the new status value (from delta data) has soft_delete = true
If yes, it sets the action to SOFT_DELETE
If no, it hard deletes the item (permanently removed from the database)
How should you handle the fact that events received via webhooks can be received in random order ?
For instance, given the following ordered event:
A: invoiceitem.created (with quantity of 1)
B: invoiceitem.updated (with quantity going from 1 to 3)
C: invoiceitem.updated (with quantity going from 3 to 2)
How do you make sure receiving C-A-B does not result in corrupted data (ie with a quantity of 2 instead of 3)?
You could reject the webhook if the previous_attributes in Event#data do not correspond to the current state, but then you are stuck if your local model was updated already, as you will never find yourself in the state expected by the webhook.
Or you can just use treat any webhook as a hint to retrieve and update an object. You just disregard the data sent by the webhook and always retrieve it.
Even if you receive events ordered as update/delete/create it should work, as update would in fact create the object, delete would delete it, and create would fail to retrieve the object and do nothing.
But it feels like a waste of resources to retrieve data each time when the webhook offers it as event data.
This question was asked before but the answers don't cover the above solutions.
Thanks
If your application is sensitive to changes like this that can occur close in time, you really should just use the event as a signal to retrieve the object, as #koopajah noted in their comment. That's the only way to ensure you have the latest state.
I have a Web API and I am using DTOs to abstract the underlying data model from the client. I have [at the moment] one DTO per controller. This DTO in all cases contains the database id of the data being passed about. On a GET, PUT, DELETE this makes sense (although DELETE and GET just use the id and not the DTO on the request obviously), but on the POST it doesn't make sense as the new data being added has no id yet.
In other words I am asking the client to pass to the API a structure that includes an Id field but I will ignore the content of that Id field. Is this acceptable or should I create an UpdateDTO and a RetrieveDto?
Keep the data structure you have. Make the Id field optional. If the value of Id is set when a POST comes in, return an error.
I am attempting to create a new Case object using the REST API but need to find out how to format the JSON body to pass in nested SObjects.
It's not apparent in the Docs, and I can't seem to find any examples. Anyone have any pointers or have done this before?
The SF web UI uses a text lookup field to set the (related) Contact and Account, and I need to figure out how to either bypass the need for a lookup or embed the SObjects of the related records in the JSON.
[{"message":"The value provided for foreign key reference Contact is not a nested SObject","errorCode":"INVALID_FIELD"}]
Figured it out by simply setting the AccountId and ContactId attributes on the new Case object.
I also haven't seen any documentation about this, but if you look at the object metadata returned by the REST API for any standard object, it seems that the suffix 'Id' is appended to any field of type "reference". For example, Case has OwnerId, LastModifiedById, CreatedById, etc. This suffix is not present in the field names displayed in the browser interface. The WSDL for the SOAP API includes both the ID as a simple element of type "ID", as well as a complex child element for nesting the actual record.