Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Forward compatibility (HATEOAS) - Discover all endpoints dynamically from api response #5

Closed
devraj opened this issue Apr 10, 2023 · 1 comment
Closed

Forward compatibility (HATEOAS) - Discover all endpoints dynamically from api response #5

devraj opened this issue Apr 10, 2023 · 1 comment
Assignees
@devraj

Comments

@devraj
Copy link
Member

devraj commented Apr 10, 2023 •
edited
Loading

According to the documentation we should not reference /api/items and some other endpoints statically, this should instead be discovered from the features.items.items.href attribute of the /api response.

To find an item, pass a substring of its name to the link at features.items.items.href in the results of a call to /api. If you are sure of its name, place the name inside " quotes, and it will use a full string match. Both types of search are case-insensitive.

This ticket is to refactor the current implementation to add discovery.

As the Gallagher documentation states this is for HATEOAS compatibility:

This is a self-referencing REST API that follows the principles of HATEOAS. Other than the initial GET to /api when it first connects, your source code should not contain any URLs, as they are subject to change. You should append the query parameters this document describes for operations such as filtering and searching, but everying in the path should come from the results of /api or pages linked from it.

/api only shows licensed API calls.

Be prepared to append query parameters to URLs that already have their own: do not assume that you can simply add a question mark and your parameters.
@devraj devraj self-assigned this Apr 10, 2023
@devraj devraj mentioned this issue Nov 21, 2023
Open
devraj added a commit that referenced this issue Nov 21, 2023
@devraj
refactor: renames APIBase to APIEndpoint
15ccf3a 
APIEndpoint is a more fitting name going fowards as we implement
discover and caching REFS #5 and #8
@devraj devraj mentioned this issue Nov 21, 2023
Closed
devraj added a commit that referenced this issue Nov 21, 2023
@devraj
docs: adds intention to api discovery parser
e43f834 
we are moving towards discovering the api endpoints dynamically, this
is a major refactor in the way the api endpoints are going to work

REFS #5 and #8
@devraj devraj mentioned this issue Nov 21, 2023
Merged
devraj added a commit that referenced this issue Nov 24, 2023
@devraj
refactor: discover api endpoints dynamically
d48390a 
gallagher command centre makes available a set of hrefs that should be
dynamically references as opposed to statically referencing api endpoints
this is the start of the change to do so. as part of this it's recommended to

- drop the root api endpoint query to be a privat endpoint
- the utils package to be renamed as core
- move the discovery contant outside of the APIEndpoint class

REFS #5
@devraj
Copy link
Member Author

devraj commented Nov 25, 2023

Further to this, the /api endpoint returns href for the features that have been licensed by the client and omits a href for ones that aren't. Our pyndatic models have each one of these set to an Optional.

All features should use this discovery result to configure itself dynamically.

devraj added a commit that referenced this issue Nov 25, 2023
@devraj
refactor: renames utils to core REFS #5
2655b8c
devraj added a commit that referenced this issue Nov 26, 2023
@devraj
refactor: first attempt a dynamic discovery
22752f9 
this is my first refactor towards getting dynamic discovery working
there are still issues with accessing the singlton to share the
discovered version around along side caching the discovery results

REFS #5
@devraj devraj changed the title Discover items endpoints dynamically from api response Discover all endpoints dynamically from api response Nov 26, 2023
devraj added a commit that referenced this issue Dec 3, 2023
@devraj
refactor: experinmental commit for dynamic discovery
4ff5ef4 
this a commit in a separate branch for me to experinment implementing
dynamic discovery of the api endpoints, at the moment because of
import cycles the singleton seems to be overrwritten

REFS #5
devraj added a commit that referenced this issue Dec 3, 2023
@devraj
refactor: dynamic configuration primarily working
8602083 
we have the discovery object being initialised when the base class
initialises and then the discovery fetches the url, note that
the href that the discover will return are fully qualified addresses

this drops using the api_base prefix

post this we need to formalies the configuration and syntax so this
scales to all endpoints

we are also yet to test for unlicensed features
REFS #5
devraj added a commit that referenced this issue Dec 3, 2023
@devraj
refactor: formalises configuration pattern for dynamic configuration
be14035 
adds context around the design of the classes and lifecycle for dynamic
discovery of api endpoints

REFS #5
@devraj devraj mentioned this issue Dec 3, 2023
Merged
@devraj devraj changed the title Discover all endpoints dynamically from api response Forward compatibility (HATEOAS) - Discover all endpoints dynamically from api response Dec 3, 2023
devraj added a commit that referenced this issue Dec 5, 2023
@devraj
refactor: moves capabilities singleton out of base class
6dd7d72 
i wasn't quite happy with the idea that the singleton was part of the
base class that all the endpoints inherited from, this is now moved
into a class called Capabilties which has a class level variable called
CURRENT to represent the current capabilities of the server we are connected
to, this reads a lot better than before

REFS #5

we should also explore if it's possible to move back to using the __config__
constants being assigned by the endpoint classes as opposed to the
method returning the configuration

there may be lifecycle issues here
devraj added a commit that referenced this issue Dec 6, 2023
@devraj
refactor: configuration syntax of discover and endpoints
b510508 
the discover endpoints drop the .href portion of the configuration this is
infered by the common runtime code, making it uncessary for each endpoint
to explicitly reference the href propeorty

this also leads us to handing #8 properly as the core runtime can check for
None type of the href property

an OptionalHref type replaces the use of the Mixin for the discover endpoints
additionally these are initialised to None and are overridden if the
feature is avaialble on the command centre

also see commentary in APIEndpoint._discover as to why we are sticking to
initialising the configuration as the result of a function not an assignment
to a class level variable

REFS #5
@devraj devraj closed this as completed Dec 6, 2023
devraj added a commit that referenced this issue Dec 27, 2023
@devraj
fix: discovery response cache not being utilised
94d2af7 
the original design intended to cache the Discovery response to conform hateoas
#5

overriding the pydantic method model_post_init to set the good_known_since var
introduced an error where the test first test would run the subsequent calls would fail
https://docs.pydantic.dev/2.0/api/main/\#pydantic.main.BaseModel.model_post_init

debugging this i found that the discover was running every time as the good_known_since
would never have been set and the cache check would fail.

initially thought of this as a bug with how parsing was working but turns out that if
the cache was detected then we were returning without initialising the configuration
against the discovery response.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@devraj devraj

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@devraj