You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For some use cases, where the data is going to be interchanged frequently, it may be beneficial for the client to cache the results from the API.
Currently there is no mechanism to support incremental updates, so I'd suggest something like an optional parameter on the query string to support only returning search results that have been updated since that date.
For example, you could call endpoints: /facilities/byCountry/GB/BIC?updateFromUtc=2018-03-06T10:39:00 to get all changes to facilities in the UK changed since 10:39 on the 6th March 2018 (UTC), or: /facilities/byLocation/GBCLL/BIC?updateFromUtc=2022-03-01T00:00:00 to get all changes to facilities in Coleshill, UK changed this year - which might pick up the change in ownership of the Hams Hall Rail Terminal which recently changed ownership from ABP to Maritime Transport
If the codeProvider could be defaulted, or moved to the query string, this could even allow for calls like /facilities/?updateFromUtc=2022-03-01T00:00:00 which could be useful for shipping lines to keep their master data in line, rather than having to periodically query all the records for the territories they're active in.
Granted this would mean that the last modified date would need to be exposed from the underlying data, for future calls to be useful
An alternative proposal, could be for interested parties to register call back URLs as subscriptions (similar to how DCSA have defined for their track and trace API) - this could then get updates reflected in near real time.
The text was updated successfully, but these errors were encountered:
One of the options we have is to do similar to the call back urls, we have a pub/sub environment setup and for example we provide new and changes to facilities to all US codes to IANA as we have a sync in place with them.
Would this option be more useful than implementing the filter by date? (we have this date for info so its easily possible)
For your subscriptions would you be looking to subscribe to only codes you have in your system(s) or for any code change?
Im wondering if you only want to manage change for those codes you have pre validated internally and have attached to records your system ? If so we would just need to allow you to subscribe to a change for a list of codes, again should be fairly straight forward as the underlying infrastructure os pub/sub is there.
Welcome your reply before considering detailing the change request, but again great feedback and really useful to understand how you are implementing !
I was thinking it would be more useful to find out about new depots in a given area;
For example, I understand GBLIVTRBO opened recently, so I could see there could be opportunities for lines to see how using that facility could help give them a commercial advantage in reduced empty running to alternatives and doing "what if" analysis prior to engaging in negotiations with the depot.
For information about a depot changing, I could only imagine that would be thigs like name/operator, rather than address details 9but in the UK, the Royal Mail do like to reassign postal codes occasionally, so that may aid, especially for integrations with transport systems that may need the new postcode to route effectively...
For some use cases, where the data is going to be interchanged frequently, it may be beneficial for the client to cache the results from the API.
Currently there is no mechanism to support incremental updates, so I'd suggest something like an optional parameter on the query string to support only returning search results that have been updated since that date.
For example, you could call endpoints:
/facilities/byCountry/GB/BIC?updateFromUtc=2018-03-06T10:39:00
to get all changes to facilities in the UK changed since 10:39 on the 6th March 2018 (UTC), or:/facilities/byLocation/GBCLL/BIC?updateFromUtc=2022-03-01T00:00:00
to get all changes to facilities in Coleshill, UK changed this year - which might pick up the change in ownership of the Hams Hall Rail Terminal which recently changed ownership from ABP to Maritime TransportIf the
codeProvider
could be defaulted, or moved to the query string, this could even allow for calls like/facilities/?updateFromUtc=2022-03-01T00:00:00
which could be useful for shipping lines to keep their master data in line, rather than having to periodically query all the records for the territories they're active in.Granted this would mean that the last modified date would need to be exposed from the underlying data, for future calls to be useful
An alternative proposal, could be for interested parties to register call back URLs as subscriptions (similar to how DCSA have defined for their track and trace API) - this could then get updates reflected in near real time.
The text was updated successfully, but these errors were encountered: