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.

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

Merge derived LayerApi and HateoasApi #14

Open
bruderj15 opened this issue Dec 24, 2024 · 0 comments
Open

Merge derived LayerApi and HateoasApi #14

bruderj15 opened this issue Dec 24, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@bruderj15
Copy link
Owner

Currently deriving the HATEOAS Layer-Api (and server) and the rewritten HATEOAS-Api exist in isolation.

In the example we get:

layerServer :: Server (Resourcify (MkLayers Api) (HAL JSON))
layerServer = getResourceServer (Proxy @Handler) (Proxy @(HAL JSON)) (Proxy @(MkLayers Api))

apiServer :: Server (Resourcify Api (HAL JSON))
apiServer = getResourceServer (Proxy @Handler) (Proxy @(HAL JSON)) (Proxy @Api)

We would want:

layerAndApiServer :: Server (Resourcify (MkLayers Api) (HAL JSON) :<|> Resourcify Api (HAL JSON))
layerAndApiServer = getResourceServer (Proxy @Handler) (Proxy @(HAL JSON)) (Proxy @(MkLayers Api))
               :<|> getResourceServer (Proxy @Handler) (Proxy @(HAL JSON)) (Proxy @Api)

This may lead to multiple server-implementations for the same endpoint.

Try an approach where we merge both server-implementations by adding all links from the one in layerServer to the one in apiServer, then discarding the one in layerServer.

@bruderj15 bruderj15 added the enhancement New feature or request label Dec 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant