awalkowiak
commented
4 years ago @johnhbenetech I want to confirm if I am on the same page. There is a request:
GET: /record-details/<id>,
then I look for given id in organizations, services and locations (looking for ids or externalDbIds like the one from request), then when I have a result I get an organization from it and return this structure:
{
organization: {
allOrganizationFields,
services: [ listOfAllServicesObjects ],
locations: [ listOfAllLocationObjects ],
listsOfAllOtherObjectsRelatedToThatOrganization
},
partnerOrganizations: [
list of matching records with the same structure as the organization above has
],
conflictingFields: [
{ entity, field, ownerVersion, resourceId, partnerVersion, partnerId, partnerName },
] // <- this conflictingFields are optional
}
Is that correct?
johnhbenetech
bognasoldev89
Create an an endpoint that only responds to authenticated and authorized API requests (see this related task : https://github.com/benetech/ServiceNet/issues/782 ).
This endpoint is intended to respond to requests in well-structured JSON to emit the full graph of any Organization record and all child records in JSON, and present a comparison to any other partner's matching record. Those "matching" partner records will be discovered via a different API endpoint defined here : https://github.com/benetech/ServiceNet/issues/783
The request should be compliant with the base HSDA standard definition here https://github.com/openreferral/api-specification but also be extended to ensure it includes functionality not incorporated into the HSDA standard that identifies which partner record it should be compared to: -The native unique identifier in the owner's database - must reside in the same partner database as is being represented in the bearer token on this request. -The Service Net unique identifier of the matching partner record
In all cases, regardless of what record type might have been specified in the request above (Organization, Service, Location), the response should always navigate up to the parent Organization record and emit that record and ALL of its child records, not just the one that might have been requested. This is to simplify the responses so that it consistently always returns the same structure which is important for this task but will be even more important in future tasks.
Since comparing differences between the requested record and one matching partner's record, the response should also contain the full graph of the matching partner record, also recursed all the way up to its Organization level and including all of its child records, as a second array element in the response.
Optionally, each field in every record of the matching partner record set should be highlighted when it differs from the value in the equivalent field in the initially requested record from the owner's database. This will only be possible at the Organization level, at the Location level where we have already detected matches, and only at the Service level once we have service-level matching in place either automatically https://github.com/benetech/ServiceNet/issues/699 or manually https://github.com/benetech/ServiceNet/issues/780.