Investigate why we are not using the contract ID consistently

[adinuca]

Why

We are using contract_id to retrieve the annotations for the search page, but we are using open_contracting_id for retrieving annotations, metadata and text when viewing a contract.

What

• Investigation is done on why we are not using the same ID of the contract everywhere
• Follow up issues are raised to make the behaviour consistent

Notes

[adinuca]

Conversation with Anjesh( it was on the wrong issue) :

Hi @anjesh ,
Do you know why we are using the contract_id to retrieve annotations for the search page but we are using open_contracting_id to retrieve annotations, metadata and text when viewing a contract?
Eg:
The following request to the API is made when the user accesses https://staging.resourcecontracts.org/contracts : /contract/84/annotations?lang=fr&category=rc
But when the user views the first contract in the results, the request for annotation will be made to /contract/ocds-591adf-8082857980/annotations?lang=fr&category=rc.

Thanks!

 @anjesh
 Member
anjesh commented 20 minutes ago
@adinuca that is the legacy issue, but both contract_id and ocid works in all the urls and APIs as far as i remember. The public site now uses ocid to retrieve the data, but contract_id works as well. We started with contract_id and later it was decided to use ocid in public sites and eventually that is reflected in APIs as well. But previous source-codes might not have been updated as it works with both ids.

 @adinuca
 Member
adinuca commented 18 minutes ago
Hi @anjesh ,
Thank you for your answer. I am not looking to deprecate this feature, I was asking because using the same ID everywhere in RC Subsites would reduce the number of calls to the API, because the call for the annotations might be already cached when a user clicks on a contract.

 @anjesh
 Member
anjesh commented 8 minutes ago
Thanks. That makes sense. Could you create an issue to update the code for consistent ids across the subsites for performance issue? We will discuss with Charles before we work on that.

 @adinuca
 Member
adinuca commented 6 minutes ago
Sure. Thank you!

[adinuca]

#1175 has been raised to deal with inconsistent requests.