Skip to content

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

Closed
wants to merge 2 commits into from
Closed

Add HAL JSON UTF-8 variant to MediaTypes #470

wants to merge 2 commits into from

Conversation

drumonii
Copy link

@drumonii drumonii commented Jul 26, 2016

Add ;charset=UTF-8 to application/hal+json similar to APPLICATION_JSON_UTF8 in MediaType

/**
* A String equivalent of {@link MediaTypes#HAL_JSON_UTF8}.
*/
public static final String HAL_JSON_UTF8_VALUE = HAL_JSON_VALUE + ";charset=UTF-8";
Copy link

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.

Copy link
Author

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.

Copy link

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 :)

Copy link
Author

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.

Copy link
Contributor

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.

@marceloverdijk
Copy link

This would be a nice addition especially as a default Boot app with the hateoas starter adds the charset to the content type.

@SympathyForTheDev
Copy link

+1 for this addition

@gregturn
Copy link
Contributor

gregturn commented Mar 20, 2017

It appears that the Spring Framework has APPLICATION_JSON_UTF8 only to support the fact that MappingJackson2HttpMessageConverter defaults to application/json ;charset=UTF-8. In other words, in that same class, there are no other UTF-8 types added to the vast list of IANA spec'd mediatypes.

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.

@drumonii
Copy link
Author

Spring Boot defaults its HTTP encoding to UTF-8 since 1.2, see here.

The issue that I came across is that if you had a test like this, it would fail.

mockMvc.perform(get("/api/test"))
		...
		.andExpect(content().contentType(MediaTypes.HAL_JSON))

java.lang.AssertionError: Content type 
Expected :application/hal+json
Actual   :application/hal+json;charset=UTF-8

Since there is a UTF-8 version of application/json in Spring Framework's MediaType, thought it would be useful if SDR had the UTF-8 version of application/hal+json in its MediaTypes for consistency.

@gregturn
Copy link
Contributor

gregturn commented Mar 26, 2017

Additionally, we need some tests for this mediatype such as in EnableHypermediaSupportIntegrationTest and TypeReferencesIntegrationTest.

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: HypermediaSupportBeanDefinitionRegistrar and HalLinkDiscovered.

Updating these spots in this PR would go a long way toward polishing things up for merging.

@drumonii
Copy link
Author

@gregturn I'll take a look at updating the tests. Will get back to you in Spring Data Gitter if I have questions.

@gregturn
Copy link
Contributor

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) {
Copy link
Author

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) {
Copy link
Author

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));
Copy link
Author

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

@drumonii
Copy link
Author

@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.

@gregturn
Copy link
Contributor

gregturn commented Apr 5, 2017

@drumonii With all the work in Berlin this week, I can hopefully take a close look next week.

@drumonii
Copy link
Author

drumonii commented Apr 5, 2017

@gregturn No worries, that sounds good!

@SympathyForTheDev
Copy link

SympathyForTheDev commented Jul 19, 2017

Hello, In what version of hateos this fix will be available ?

@gregturn
Copy link
Contributor

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.

@odrotbohm
Copy link
Member

@drumonii — Would you mind to provide us with your full name and a proper email address?

@odrotbohm odrotbohm assigned odrotbohm and unassigned gregturn Sep 7, 2017
@odrotbohm odrotbohm added this to the 0.24 milestone Sep 7, 2017
@odrotbohm
Copy link
Member

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.

odrotbohm added a commit that referenced this pull request Sep 7, 2017
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.
@odrotbohm odrotbohm closed this Sep 7, 2017
@odrotbohm odrotbohm changed the title Add HAL_JSON_UTF8 to MediaTypes Add HAL JSON UTF-8 variant to MediaTypes Sep 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants