Added hypermedia support in the form of a DiscoveredResource abstraction #76
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
odrotbohm
force-pushed
the
hypermedia
branch
2 times, most recently
from
9e3fa1d
to
7a64384
Compare
| } | ||
|
|
||
| @Data | ||
| @ConfigurationProperties(prefix = "cloud.hypermedia") |
There was a problem hiding this comment.
We've been prefixing with spring.cloud.
|
From your description: |
|
So this would replace this kind of work? |
|
Re: naming in the commit message — indeed, I changed a few names and extracted interfaces in the course of writing up the summary and adding test cases. Re: replacement — right, the client now looks like this (although that particular variant still uses |
|
@olivergierke awesome! That configuration link helps me see the power of this change! |
odrotbohm
force-pushed
the
hypermedia
branch
from
7a64384
to
b91d934
Compare
|
I've changed the config properties namespace to |
|
@dsyer @marcingrzejszczak or @adriancole any comments? |
|
|
||
| return link; | ||
|
|
||
| } catch (RestClientException o_O) { |
There was a problem hiding this comment.
The exception variable is awesome :)
|
@olivergierke the following tests fail With the following errors respectively: and |
This commit introduces support to easily discover resources in remote
service APIs and periodically validating they're still available.
The core concept is a RemoteResource and its primary implementation
DiscoveredResource which consists of a ServiceInstanceProvider and a
TraversalDescription. The service instance provider abstracts the location
of the service the DiscoveredResource is hosted at. Currently there are
two implementations available: a StaticServiceInstanceProvider that — as
the name suggests — returns a statically configured instance, as well as
the DynamicServiceInstanceProvider which takes a DiscoveryClient and service
name as input to dynamically discover the ServiceInstance on request.
The TraversalDefinition is a SAM type that allows to define the path traversals
that shall be executed to discover the target resource within the service
instance. This allows the following configuration:
DiscoveryClient client = …
ServiceInstanceProvider provider = new DynamicServiceInstanceProvider(client, "stores");
RemoteResource resource = new DiscoveredResource(provider, traverson -> traverson.follow("stores", "search", "by-location");
This will cause the following to happen:
1. In this default state the resource is undiscovered and calls to getLink()
will return null.
2. A call to verifyOrDiscover() will trigger resource discovery, i.e. lookup
the service instance using the discovery client, execute the path traversal
as defined and store the final link discovered ("by-location") in the
discovered resource.
3. Calls to getLink() will return that link. Calls to verifyOrDiscover()
will issue a HEAD request to verify the resource is still available and
reset the link if not. Subsequent calls to verifyOrDiscover() will trigger
rediscovery.
That means that we basically shield against either the service instance becoming
unavailable or the resource becoming unavailable within the service instance
(due to some URI restructuring or the like).
The calls to verifyOrDiscover() are currently automated by a RemoteResourceRefresher
which is auto-configured if a RemoteResource is declared as Spring bean
and its initial and fixed delay can be configured via properties in the
spring.cloud.hypermedia namespace.
|
That should be fixed :). |
spencergibb
added a commit
that referenced
this pull request
Jan 13, 2016
Added hypermedia support in the form of a DiscoveredResource abstraction
|
@olivergierke does this PR let links be loadbalanced? http://stackoverflow.com/questions/34792288/spring-data-rest-links-and-ribbon-client-loadbalancer |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit introduces support to easily discover resources in remote service APIs and periodically validating they're still available.
The core concept is a
DiscoveredResourceand its primary implementationTraversingDiscoveredResourcewhich consists of aServiceInstanceProviderand aTraversalDescription. The service instance provider abstracts the location of the service theDiscoveredResourceis hosted at. Currently there are two implementations available: aStaticServiceInstanceProviderthat — as the name suggests — returns a statically configured instance, as well as theDynamicServiceInstanceProviderwhich takes aDiscoveryClientand service name as input to dynamically discover theServiceInstanceon request.The
TraversalDefinitionis a SAM type that allows to define the path traversals that shall be executed to discover the target resource within the service instance. This allows the following configuration:This will cause the following to happen:
….getLink()will returnnull.….verifyOrDiscover()will trigger resource discovery, i.e. lookup the service instance using the discovery client, execute the path traversal as defined and store the final link discovered ("by-location") in the discovered resource.….getLink()will return that link. Calls to….verifyOrDiscover()will issue aHEADrequest to verify the resource is still available and reset the link if not. Subsequent calls to….verifyOrDiscover()will trigger rediscovery.That means that we basically shield against either the service instance becoming unavailable or the resource becoming unavailable within the service instance (due to some URI restructuring or the like).
The calls to
….verifyOrDiscover()are currently automated by aDiscoveredResourceRefresherwhich is auto-configured if aDiscoveredResourceis declared as Spring bean and its initial and fixed delay can be configured via properties in thecloud.hypermedianamespace.