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

Pick a default set of media types for @EnableHypermediaSupport #1015

Closed
gregturn opened this issue Jul 8, 2019 · 4 comments · May be fixed by #1265
Closed

Pick a default set of media types for @EnableHypermediaSupport #1015

gregturn opened this issue Jul 8, 2019 · 4 comments · May be fixed by #1265
Assignees
Labels

Comments

@gregturn
Copy link
Contributor

gregturn commented Jul 8, 2019

Instead of manually requiring setting the types field when using this annotation, let's select a default set of media types, whether that's simply HAL to match what is done historically, or whether it's to enable all support media types.

Or perhaps we can it be a little more sophisticated and have an HypermediaType type that says to activate all discovered media types dynamically.

@odrotbohm
Copy link
Member

I remember having a discussion with @wilkinsona about this. The challenge here is to make things reasonably but at the same time to be careful that we don't necessarily change user's APIs just because we decide to add support for a new media type as that might be surprising.

We also have to make up our minds on how explicitly activating media type support contributed via an extension plays into this.

@gregturn
Copy link
Contributor Author

gregturn commented Jul 9, 2019

Is go for at least these options (if it’s not too complicated):

  • LEGACY - activates HAL and nothing else
  • SUPPORTED - activates all of the supported but not 3rd party
  • SCANNED - activates all 3rd party types
  • SUPPORTED_AND_SCANNED - everything

The names are up for grabs but these seem like the most logical groupings to me. If we also need something for HAL + HAL_FORMS I also wouldn’t object.

@gregturn
Copy link
Contributor Author

gregturn commented Apr 9, 2020

Spring Boot simply has @EnableHypermediaSupport(HAL), which defaults to HAL. Check out #1060, and its ability to allow users to simply use @EnableHypermediaSupport, and have ALL registered hypermedia supports enabled.

@gregturn gregturn added this to the 1.1.0.M4 milestone Apr 9, 2020
@gregturn gregturn added the in: configuration Configuration and setup label Apr 9, 2020
@gregturn gregturn self-assigned this Apr 9, 2020
gregturn added a commit that referenced this issue Apr 9, 2020
Default it to being empty. Existing code, `@EnableHypermediaSupport(types = HAL)` will still operate as expected. But simply using the annotation with no arguments will activate ALL types.

Related issues: #1015.
Related pull request: #1065.
gregturn added a commit that referenced this issue Apr 9, 2020
Default it to being empty. Existing code, `@EnableHypermediaSupport(types = HAL)` will still operate as expected. But simply using the annotation with no arguments will activate ALL types.

Related issues: #1015.
Related pull request: #1065, #1265.
gregturn added a commit that referenced this issue Apr 9, 2020
Default it to being empty. Existing code, `@EnableHypermediaSupport(types = HAL)` will still operate as expected. But simply using the annotation with no arguments will activate ALL types.

Related issues: #1015.
Related pull request: #1065, #1265.
gregturn added a commit that referenced this issue Apr 9, 2020
Default it to being empty. Existing code, `@EnableHypermediaSupport(types = HAL)` will still operate as expected. But simply using the annotation with no arguments will activate ALL types.

Related issues: #1015.
Related pull request: #1065, #1265.
@gregturn gregturn modified the milestones: 1.1.0.RC1, 1.1.0.RELEASE Apr 27, 2020
@gregturn
Copy link
Contributor Author

gregturn commented May 6, 2020

Closing this out in favor of letting #1060 support a "null" or "empty" configuration, where it will NOT enable any of our pre-built hypermedia types, and instead simply fall back to whatever custom ones the user has designed.

@gregturn gregturn closed this as completed May 6, 2020
@gregturn gregturn removed this from the 1.1.0.RELEASE milestone May 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants