-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create a method to query which version of LCF an endpoint implements #327
Comments
In considering this, I think there are two items we should resolve:
Recommended changes are therefore: E16 LCF VERSIONDescriptionThe VERSION entity enables LCF implementations to respond, answering the question "Which LCF version are you?" Properties
e.g.
|
This sounds logical to me, but I'm wondering how this could be implemented in a backwards-compatible way. Any existing implementation won't support the new entity E16. Presumably, if the "which LCF version are you?" GET request is made to an existing implementation, the HTTP response will be an exception of some kind or a '404', in which case the client will know to fall back on the current request style (including '1.0' in the request URI path). If the request is successful and the version number is returned, the client can continue using the new request style. |
Yes, that's right. Given the Use Case, where a terminal application is communicating with multiple LCF endpoints, the terminal application will require code to handle each version of LCF as they are implemented over time. ie, Customer A running LCF 1.2.0, and Customer B running LCF 1.3.0. The client therefore needs the mechanism to determine which version of LCF it is communicating with and update the URIs it will invoke for each version of LCF it supports. With this proposal, This means the change is a breaking change to the LCF definition, however it can be seamlessly handled by terminal applications. We could add a page describing a recommended implementation pattern to permit transitions of LCF versions. Would that be helpful? |
I'm slightly in two minds as to whether this is a breaking change across the whole of LCF or just in the REST web service specification. But, on reflection, it is probably cleaner to make it a breaking change across the board, so that we can fix the version number in entity E16 for each released version of LCF in both the Data Framework and the entity XML binding. |
As an example, here's a schematic of how the client can handle changing LCF versions with minimal impact. In this model, the client only needs to update the respective "client" class with any changes, inheriting previous behaviour from earlier versions through inheritance (extension) of the previous client implementation. I agree about resolving the version numbering issues cleanly. If we don't we are only storing technical debt for the future. |
A terminal client can be provided as a SaaS web solution, enabling the terminal client vendor to provide services hosted from a single location and benefit from the economies of scale. This presents an issue, that each library customer could be operating a different implementation version of LCF, however, there is no current mechanism to positively request and respond to the question of "Which version of LCF are you running?"
Can we implement a simple URI / Entity to enable an electronic system to proactively request the implementation version number from an LCF deployment?
eg.
Request
GET /lcf {with no other components}
Response
HTTP/200 - OK
1.3.5
The text was updated successfully, but these errors were encountered: