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

Confused about content-type (application/json+fhir) #445

Closed
Robbert1 opened this Issue Sep 13, 2016 · 7 comments

Comments

Projects
None yet
2 participants
@Robbert1

Robbert1 commented Sep 13, 2016

Hi,

Currently the HAPI-FHIR JPA server returns results as content-type "application/json+fhir".

This is also stated here:
https://www.hl7.org/fhir/json.html
https://www.hl7.org/fhir/valueset-content-type.json.html

however this site states "application/fhir+json" which I feel is actually more correct as general JSON parsers like Springs AbstractJackson2HttpMessageConverter are configured to work for "application/*+json".

Although it's not yet a real spec by my knowledge, I do believe more custom JSON based content types like HAL also conform to this pattern.

I'd like to get some info on if any switch to "application/fhir+json" is planned or if "application/json+fhir" is the definitive type.

@jamesagnew

This comment has been minimized.

Show comment
Hide comment
@jamesagnew

jamesagnew Sep 13, 2016

Owner

Hi @Robbert1,

FHIR itself defines the content types we use as they have them spelled out as requirements in the specification.

One of the changes in the current STU3 ballot is that they've shifted from using application/json+fhir to using application/fhir+json (and same change for XML).

This change is reflected in HAPI's 2.0 release, but only in STU3 mode (i.e. DSTU3 contexts). You can see the updated content types in the request and response headers here for example: http://fhirtest.uhn.ca/conformance?serverId=home_21&pretty=true

Owner

jamesagnew commented Sep 13, 2016

Hi @Robbert1,

FHIR itself defines the content types we use as they have them spelled out as requirements in the specification.

One of the changes in the current STU3 ballot is that they've shifted from using application/json+fhir to using application/fhir+json (and same change for XML).

This change is reflected in HAPI's 2.0 release, but only in STU3 mode (i.e. DSTU3 contexts). You can see the updated content types in the request and response headers here for example: http://fhirtest.uhn.ca/conformance?serverId=home_21&pretty=true

@jamesagnew

This comment has been minimized.

Show comment
Hide comment
@jamesagnew

jamesagnew Sep 13, 2016

Owner

...although I notice that the types are actually wrong in the conformance statement itself. Argh!

I'll keep this bug open to track that. :)

Owner

jamesagnew commented Sep 13, 2016

...although I notice that the types are actually wrong in the conformance statement itself. Argh!

I'll keep this bug open to track that. :)

@Robbert1

This comment has been minimized.

Show comment
Hide comment
@Robbert1

Robbert1 Sep 13, 2016

I'm actually using HAPI 2.0 with STU3. (my server response contains X-Powered-By=[HAPI FHIR 2.0 REST Server (FHIR Server; FHIR 1.6.0/DSTU3)])

Robbert1 commented Sep 13, 2016

I'm actually using HAPI 2.0 with STU3. (my server response contains X-Powered-By=[HAPI FHIR 2.0 REST Server (FHIR Server; FHIR 1.6.0/DSTU3)])

@jamesagnew

This comment has been minimized.

Show comment
Hide comment
@jamesagnew

jamesagnew Sep 13, 2016

Owner

Is the client you're using sending the correct Accept header? In order to avoid breaking existing clients, HAPI tries to negotiate and will pick "the old or the new" depending on what the request looks like.

Owner

jamesagnew commented Sep 13, 2016

Is the client you're using sending the correct Accept header? In order to avoid breaking existing clients, HAPI tries to negotiate and will pick "the old or the new" depending on what the request looks like.

@jamesagnew

This comment has been minimized.

Show comment
Hide comment
@jamesagnew

jamesagnew Sep 13, 2016

Owner

E.g. the following is required to get the new content type from our public server:

$ curl -H "Accept: application/fhir+json" --head "http://fhirtest.uhn.ca/baseDstu3/metadata"
HTTP/1.1 405 Method Not Allowed
Date: Tue, 13 Sep 2016 14:18:47 GMT
Server: Apache-Coyote/1.1
X-Powered-By: HAPI FHIR 2.1-SNAPSHOT REST Server (FHIR Server; FHIR 1.6.0/DSTU3)
Allow: GET
Content-Type: application/fhir+json;charset=UTF-8
Transfer-Encoding: chunked
Connection: close
Owner

jamesagnew commented Sep 13, 2016

E.g. the following is required to get the new content type from our public server:

$ curl -H "Accept: application/fhir+json" --head "http://fhirtest.uhn.ca/baseDstu3/metadata"
HTTP/1.1 405 Method Not Allowed
Date: Tue, 13 Sep 2016 14:18:47 GMT
Server: Apache-Coyote/1.1
X-Powered-By: HAPI FHIR 2.1-SNAPSHOT REST Server (FHIR Server; FHIR 1.6.0/DSTU3)
Allow: GET
Content-Type: application/fhir+json;charset=UTF-8
Transfer-Encoding: chunked
Connection: close
@Robbert1

This comment has been minimized.

Show comment
Hide comment
@Robbert1

Robbert1 Sep 13, 2016

The accept header is working like a charm thanks!

Robbert1 commented Sep 13, 2016

The accept header is working like a charm thanks!

@jamesagnew

This comment has been minimized.

Show comment
Hide comment
@jamesagnew

jamesagnew Sep 29, 2016

Owner

Closing this issue as it seems to be all good. :)

Owner

jamesagnew commented Sep 29, 2016

Closing this issue as it seems to be all good. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment