-
Notifications
You must be signed in to change notification settings - Fork 470
Add HAL JSON UTF-8 variant to MediaTypes #470
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
Conversation
/** | ||
* A String equivalent of {@link MediaTypes#HAL_JSON_UTF8}. | ||
*/ | ||
public static final String HAL_JSON_UTF8_VALUE = HAL_JSON_VALUE + ";charset=UTF-8"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of doing String concatenation, I would write = "application/hal+json;charset=UTF-8"
, to make this easier to grep and to understand. It would be similar to org.springframework.http.MediaType
.
Also, I think we should add an underscore to "UTF8" in the constant names: HAL_JSON_UTF_8_VALUE. It's more readable, and it seems to be more conventional when looking at the Spring / Guava / JDK codebases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree about the String concatenation, but it's interesting you mention MediaType
because that's where I modeled my hal+json
additions from. See this line
Also it uses UTF8
instead of UTF_8
as you suggested. Just want to be consistent how the current framework does it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, I missed that "APPLICATION_JSON_UTF8_VALUE" constant in MediaType... It's weird that they chose to write it like that, since Guava / Spring / JDK seem to prefer the underscore everywhere else (I even cloned a few Spring project and grep'ed to check :D ).
I guess it makes sense in a way, since you clearly separate the "HAL" / "JSON" and "UTF 8" info. We should probably go for consistency with MediaTypes.
Anyway I created a temporary class "AdditionalMediaTypes" in my project, until we can get this in Spring HATEOAS. Great suggestion :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Yeah, I had to do the same to have a hal+json
media type with ;charset=UTF-8
. Hopefully this gets in the next release.
I agree it's an odd way to write it but in this situation I'd rather keep it as Spring's MediaType
does rather than be different only here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based upon Spring's MediaType being:
/**
* Public constant media type for {@code application/json;charset=UTF-8}.
*/
public final static MediaType APPLICATION_JSON_UTF8;
/**
* A String equivalent of {@link MediaType#APPLICATION_JSON_UTF8}.
*/
public final static String APPLICATION_JSON_UTF8_VALUE = APPLICATION_JSON_VALUE + ";charset=UTF-8";
...I think the proposed fix is crafted properly.
This would be a nice addition especially as a default Boot app with the hateoas starter adds the charset to the content type. |
+1 for this addition |
It appears that the Spring Framework has APPLICATION_JSON_UTF8 only to support the fact that So my question is, why do we need to add one for HAL in this project? Is something breaking because of it? Can you draft a test case or scenario where this is causing issues? Otherwise, most of the dialog has been about how to implement the solution to a problem not well defined. |
Spring Boot defaults its HTTP encoding to The issue that I came across is that if you had a test like this, it would fail.
Since there is a |
Additionally, we need some tests for this mediatype such as in In fact, if you blanket check for usage of the media type, there are other classes that must be revised based on such a change including: Updating these spots in this PR would go a long way toward polishing things up for merging. |
@gregturn I'll take a look at updating the tests. Will get back to you in Spring Data Gitter if I have questions. |
Thanks. FYI @'ing me here is more effective to reach me than gitter. :) |
*/ | ||
public JsonPathLinkDiscoverer(String pathTemplate, MediaType mediaType) { | ||
|
||
public JsonPathLinkDiscoverer(String pathTemplate, MediaType... mediaTypes) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wasn't quite sure what to do with this constructor. It seems that the MediaType
is nullable so I made it varargs. I thought about another constructor with a List
of MediaType
...
if (this.mediaTypes == null) { | ||
return true; | ||
} else { | ||
for (MediaType mediaType : this.mediaTypes) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wasn't sure what to do here either with the List
of MediaType
and isCompatibleWith
@@ -82,12 +83,17 @@ public void setUp() { | |||
@Test | |||
public void usesResourceTypeReference() { | |||
|
|||
server.expect(requestTo("/resource")).andRespond(withSuccess(RESOURCE, MediaTypes.HAL_JSON)); | |||
server.expect(times(1), requestTo("/resource")).andRespond(withSuccess(RESOURCE, MediaTypes.HAL_JSON)); | |||
server.expect(times(1), requestTo("/resource")).andRespond(withSuccess(RESOURCE, MediaTypes.HAL_JSON_UTF8)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Duplicated server expect with MediaTypes.HAL_JSON_UTF8
. Not sure the preferred way to test the MediaTypes.HAL_JSON
in addition to MediaTypes.HAL_JSON_UTF8
@gregturn initial polish of PR with tests is up! See my comments on unsure spots. Let me know what changes or additions elsewhere should be made. Thanks. |
@drumonii With all the work in Berlin this week, I can hopefully take a close look next week. |
@gregturn No worries, that sounds good! |
Hello, In what version of hateos this fix will be available ? |
I honestly don't know. Outcome of Berlin was to work on Affordances. That took weeks and based on the outcome we are taking a different approach. I'm presently coding HAL-Forms media type and using all my lessons learned on Affordances to write a lighter version of such an API. That along with all the work on Spring Data 2 has barred Oliver from reviewing the other PRs on this project. |
@drumonii — Would you mind to provide us with your full name and a proper email address? |
Actually, nevermind. I'll have to roll back most of the changes you made anyway except the addition of the addition of the media types. |
Added application/hal+json;charset=UTF-8 to the media types enum. Traverson now configures all HAL flavors to be supported by the registered HAL-specific HttpMessageConverter. Removed nullability of media type in JsonPathLinkDiscoverer. This requires subclasses that want to support all media types to explicitly configure MediaType.ALL. Heavily inspired by the PR submitted by @Drummond but very significantly rewritten.
Add
;charset=UTF-8
toapplication/hal+json
similar toAPPLICATION_JSON_UTF8
inMediaType