Exploring basic rules
Let's try exploring the /assets endpoint:
Just invoking it reveals empty set.
Now let's attempt creating some asset:
Error states that the only accepted Content-Type is application/json.
Let's satisfy the Content-type requirement:
Error states that no data has been found in JSON body.
.. index:: Asset
Let's create asset with the minimal data set:
The object you're trying to add initially receives draft status. For the asset to be created within the Registry, it should be manually switched to pending status (2 Phase Commit mechanism):
Success! Now we can see that new object was created. Response code is 201 and Location response header reports the location of the created object. The body of response reveals the information about the created asset: its internal id (that matches the Location segment), its official assetID and dateModified datestamp stating the moment in time when asset was last modified. Pay attention to the assetType. Note that asset is created with pending status.
Let's access the URL of the created object (the Location header of the response):
We can see the same response we got after creating asset.
Let's see what listing of assets reveals us:
We do see the internal id of a asset (that can be used to construct full URL by prepending http://lb.api-sandbox.registry.ea2.openprocurement.net/api/<api_version>/assets/) and its dateModified datestamp.
Let's create another asset:
After switching this object to pending, let's check what assets registry contains:
And indeed we have 2 assets now.
Let's update asset description:
We see the added properties have merged with existing asset data. Additionally, the dateModified property was updated to reflect the last modification date stamp.
Note that the asset can be modified only within the rectification period (up to rectificationPeriod.endDate).
Checking the listing again reflects the new modification date:
Let's modify one of the items added before:
Let's delete asset.
Firstly, a document with the documentType: canellationDetails has to be added:
And now asset can be easily deleted:
Integration with lots
As long as the lot is formed, the system should verify whether the asset can be attached to that lot. With the lot status being changed to verification the asset automatically reaches verification as well.
In case of the asset being available, its status automatically becomes active.
If the lot is formed incorrectly, the asset will automatically receive pending status and so that the relatedLot field will be empty.
As long as the lot status becomes either pending.deleted or pending.dissolution, the asset attached to that lot also receives pending status.
As long as the lot receives pending.sold status, the asset attached to that lot becomes complete.