You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Vidar Ramdal <vi...@idium.no> on 2010/03/08 09:08:02 UTC
Re: Let SlingPostServlet return JSON (WAS: Re: Client JSon Calls)
On Thu, Jan 28, 2010 at 3:10 PM, Vidar Ramdal <vi...@idium.no> wrote:
> Finally, we implement the logic for choosing either sendHtml() or
> sendJson(), based on:
> 1. The format of the posted data - if JSON is posted (SLING-1172),
> return JSON, otherwise return HTML
> 2. The Accept HTTP header - if set to "application/json" return JSON,
> otherwise return HTML
> 3. Possibly also an :accept form field, with the same value as the
> HTTP header, in case it is proven that setting the HTTP header does
> not work in some browsers
I have a patch for this ready at
https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12446912
Here's how it's implemented:
1. A class JSONResponse which extends HtmlResponse (for backward compatibility)
2. A class MediaRangeList for parsing the HTTP Accept header
3. A method SlingPostServlet.createHtmlResponse for determining which
format (HTML/JSON) to return to the client
The JSON format is kept as close to the HTML format as possible.
JSON is only returned if the client sends "application/json" in the
Accept header, with a greater preference than text/html. Also, the
Accept header can be simulated by a the :http-equiv-accept query
parameter.
I dropped the automatic return of JSON on JSON posts (SLING-1172) - I
think the client should specify application/json in Accept anyway, if
it wants JSON returned.
WDYT? Is this a sensible way of implementing this?
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070
Re: Let SlingPostServlet return JSON (WAS: Re: Client JSon Calls)
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 08.03.2010 12:07, Vidar Ramdal wrote:
>>>> On 08.03.2010 09:08, Vidar Ramdal wrote:
>>>>> On Thu, Jan 28, 2010 at 3:10 PM, Vidar Ramdal <vi...@idium.no> wrote:
>>>>>> Finally, we implement the logic for choosing either sendHtml() or
>>>>>> sendJson(), based on:
>>>>>> 1. The format of the posted data - if JSON is posted (SLING-1172),
>>>>>> return JSON, otherwise return HTML
>>>>>> 2. The Accept HTTP header - if set to "application/json" return JSON,
>>>>>> otherwise return HTML
>>>>>> 3. Possibly also an :accept form field, with the same value as the
>>>>>> HTTP header, in case it is proven that setting the HTTP header does
>>>>>> not work in some browsers
>>>>>
>>>>> I have a patch for this ready at
>>>>> https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12446912
>>>>>
>>>>> Here's how it's implemented:
>>>>> 1. A class JSONResponse which extends HtmlResponse (for backward compatibility)
>>>>> 2. A class MediaRangeList for parsing the HTTP Accept header
>>>>> 3. A method SlingPostServlet.createHtmlResponse for determining which
>>>>> format (HTML/JSON) to return to the client
>>>>>
>>>>> The JSON format is kept as close to the HTML format as possible.
>>>>>
>>>>> JSON is only returned if the client sends "application/json" in the
>>>>> Accept header, with a greater preference than text/html. Also, the
>>>>> Accept header can be simulated by a the :http-equiv-accept query
>>>>> parameter.
>>>>> I dropped the automatic return of JSON on JSON posts (SLING-1172) - I
>>>>> think the client should specify application/json in Accept anyway, if
>>>>> it wants JSON returned.
>>>>>
>>>>> WDYT? Is this a sensible way of implementing this?
>
>>> On Mon, Mar 8, 2010 at 9:44 AM, Felix Meschberger <fm...@gmail.com> wrote:
>>>> It hink this is basically a good idea. Esp. having the overwrite parameter.
>>>>
>>>> Though for symmetry with GET requests, where the .json extension ask for
>>>> a JSON response, we might want to also support this for POST ... Don't
>>>> have a very string preference, though.
>
>> On 08.03.2010 11:26, Vidar Ramdal wrote:
>>> Yes, I think we have been discussing this before. The problem is, what
>>> if you want to post to a JSON file (e.g.
>>> http://localhost:8080/content/file.json)?
>
> On Mon, Mar 8, 2010 at 11:47 AM, Felix Meschberger <fm...@gmail.com> wrote:
>> Hmm, what is the target resource's name ?
>
> In my example the target resource is /content/file.json
>
>> Is it "/content/file" ? Then it is a .json request but you post to
>> /content/file.
>>
>> Is it "/content/file.json" ? Then it is not a .json request because
>> there is no request extension.
>
> So, if I want to post a JSON file and have a JSON response, the
> request URL would be /content/file.json.json?
>
>>> You probably want a JSON response in those cases too, but I fear this
>>> could become inconsistent.
>>>
>>> Also, strictly speaking, the Accept header will probably say that the
>>> client prefers a text/html response (which is what web browsers do as
>>> default). So, to strictly comply with RFC 2616 [1], we should return
>>> HTML when we're able to, and the client has not specified a preference
>>> for something else.
>>>
>>> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1
>>
>> But probably you are right. If we want to have JSON requests we are
>> probably in more control over the request (app request or XHR request)
>> than using a regular post and requiring the Accept header (or the
>> overwrite parameter) might be correct).
>>
>> (in fact sending back JSON as a response to a .json request is already
>> bending the standard because we are ignoring the Accept header altogether)
>
> Well, web browsers seems to always send */* as fallback. E.g., Firefox
> sends this:
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>
> So, it prefers text/html, but will accept anything (*/*) if the other
> media types are unavailable. So "legally" we could return anything,
> but since we "can" produce text/html, I guess we should.
>
Ok, this lifted my last shade of doubt. Thanks.
Regards
Felix
Re: Let SlingPostServlet return JSON (WAS: Re: Client JSon Calls)
Posted by Vidar Ramdal <vi...@idium.no>.
>>> On 08.03.2010 09:08, Vidar Ramdal wrote:
>>>> On Thu, Jan 28, 2010 at 3:10 PM, Vidar Ramdal <vi...@idium.no> wrote:
>>>>> Finally, we implement the logic for choosing either sendHtml() or
>>>>> sendJson(), based on:
>>>>> 1. The format of the posted data - if JSON is posted (SLING-1172),
>>>>> return JSON, otherwise return HTML
>>>>> 2. The Accept HTTP header - if set to "application/json" return JSON,
>>>>> otherwise return HTML
>>>>> 3. Possibly also an :accept form field, with the same value as the
>>>>> HTTP header, in case it is proven that setting the HTTP header does
>>>>> not work in some browsers
>>>>
>>>> I have a patch for this ready at
>>>> https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12446912
>>>>
>>>> Here's how it's implemented:
>>>> 1. A class JSONResponse which extends HtmlResponse (for backward compatibility)
>>>> 2. A class MediaRangeList for parsing the HTTP Accept header
>>>> 3. A method SlingPostServlet.createHtmlResponse for determining which
>>>> format (HTML/JSON) to return to the client
>>>>
>>>> The JSON format is kept as close to the HTML format as possible.
>>>>
>>>> JSON is only returned if the client sends "application/json" in the
>>>> Accept header, with a greater preference than text/html. Also, the
>>>> Accept header can be simulated by a the :http-equiv-accept query
>>>> parameter.
>>>> I dropped the automatic return of JSON on JSON posts (SLING-1172) - I
>>>> think the client should specify application/json in Accept anyway, if
>>>> it wants JSON returned.
>>>>
>>>> WDYT? Is this a sensible way of implementing this?
>> On Mon, Mar 8, 2010 at 9:44 AM, Felix Meschberger <fm...@gmail.com> wrote:
>>> It hink this is basically a good idea. Esp. having the overwrite parameter.
>>>
>>> Though for symmetry with GET requests, where the .json extension ask for
>>> a JSON response, we might want to also support this for POST ... Don't
>>> have a very string preference, though.
> On 08.03.2010 11:26, Vidar Ramdal wrote:
>> Yes, I think we have been discussing this before. The problem is, what
>> if you want to post to a JSON file (e.g.
>> http://localhost:8080/content/file.json)?
On Mon, Mar 8, 2010 at 11:47 AM, Felix Meschberger <fm...@gmail.com> wrote:
> Hmm, what is the target resource's name ?
In my example the target resource is /content/file.json
> Is it "/content/file" ? Then it is a .json request but you post to
> /content/file.
>
> Is it "/content/file.json" ? Then it is not a .json request because
> there is no request extension.
So, if I want to post a JSON file and have a JSON response, the
request URL would be /content/file.json.json?
>> You probably want a JSON response in those cases too, but I fear this
>> could become inconsistent.
>>
>> Also, strictly speaking, the Accept header will probably say that the
>> client prefers a text/html response (which is what web browsers do as
>> default). So, to strictly comply with RFC 2616 [1], we should return
>> HTML when we're able to, and the client has not specified a preference
>> for something else.
>>
>> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1
>
> But probably you are right. If we want to have JSON requests we are
> probably in more control over the request (app request or XHR request)
> than using a regular post and requiring the Accept header (or the
> overwrite parameter) might be correct).
>
> (in fact sending back JSON as a response to a .json request is already
> bending the standard because we are ignoring the Accept header altogether)
Well, web browsers seems to always send */* as fallback. E.g., Firefox
sends this:
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
So, it prefers text/html, but will accept anything (*/*) if the other
media types are unavailable. So "legally" we could return anything,
but since we "can" produce text/html, I guess we should.
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070
Re: Let SlingPostServlet return JSON (WAS: Re: Client JSon Calls)
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 08.03.2010 11:26, Vidar Ramdal wrote:
> On Mon, Mar 8, 2010 at 9:44 AM, Felix Meschberger <fm...@gmail.com> wrote:
>> Hi,
>>
>> On 08.03.2010 09:08, Vidar Ramdal wrote:
>>> On Thu, Jan 28, 2010 at 3:10 PM, Vidar Ramdal <vi...@idium.no> wrote:
>>>> Finally, we implement the logic for choosing either sendHtml() or
>>>> sendJson(), based on:
>>>> 1. The format of the posted data - if JSON is posted (SLING-1172),
>>>> return JSON, otherwise return HTML
>>>> 2. The Accept HTTP header - if set to "application/json" return JSON,
>>>> otherwise return HTML
>>>> 3. Possibly also an :accept form field, with the same value as the
>>>> HTTP header, in case it is proven that setting the HTTP header does
>>>> not work in some browsers
>>>
>>> I have a patch for this ready at
>>> https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12446912
>>>
>>> Here's how it's implemented:
>>> 1. A class JSONResponse which extends HtmlResponse (for backward compatibility)
>>> 2. A class MediaRangeList for parsing the HTTP Accept header
>>> 3. A method SlingPostServlet.createHtmlResponse for determining which
>>> format (HTML/JSON) to return to the client
>>>
>>> The JSON format is kept as close to the HTML format as possible.
>>>
>>> JSON is only returned if the client sends "application/json" in the
>>> Accept header, with a greater preference than text/html. Also, the
>>> Accept header can be simulated by a the :http-equiv-accept query
>>> parameter.
>>> I dropped the automatic return of JSON on JSON posts (SLING-1172) - I
>>> think the client should specify application/json in Accept anyway, if
>>> it wants JSON returned.
>>>
>>> WDYT? Is this a sensible way of implementing this?
>>
>> It hink this is basically a good idea. Esp. having the overwrite parameter.
>>
>> Though for symmetry with GET requests, where the .json extension ask for
>> a JSON response, we might want to also support this for POST ... Don't
>> have a very string preference, though.
>
> Yes, I think we have been discussing this before. The problem is, what
> if you want to post to a JSON file (e.g.
> http://localhost:8080/content/file.json)?
Hmm, what is the target resource's name ?
Is it "/content/file" ? Then it is a .json request but you post to
/content/file.
Is it "/content/file.json" ? Then it is not a .json request because
there is no request extension.
> You probably want a JSON response in those cases too, but I fear this
> could become inconsistent.
>
> Also, strictly speaking, the Accept header will probably say that the
> client prefers a text/html response (which is what web browsers do as
> default). So, to strictly comply with RFC 2616 [1], we should return
> HTML when we're able to, and the client has not specified a preference
> for something else.
>
> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1
But probably you are right. If we want to have JSON requests we are
probably in more control over the request (app request or XHR request)
than using a regular post and requiring the Accept header (or the
overwrite parameter) might be correct).
(in fact sending back JSON as a response to a .json request is already
bending the standard because we are ignoring the Accept header altogether)
Regards
Felix
>
Re: Let SlingPostServlet return JSON (WAS: Re: Client JSon Calls)
Posted by Vidar Ramdal <vi...@idium.no>.
On Mon, Mar 8, 2010 at 9:44 AM, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> On 08.03.2010 09:08, Vidar Ramdal wrote:
>> On Thu, Jan 28, 2010 at 3:10 PM, Vidar Ramdal <vi...@idium.no> wrote:
>>> Finally, we implement the logic for choosing either sendHtml() or
>>> sendJson(), based on:
>>> 1. The format of the posted data - if JSON is posted (SLING-1172),
>>> return JSON, otherwise return HTML
>>> 2. The Accept HTTP header - if set to "application/json" return JSON,
>>> otherwise return HTML
>>> 3. Possibly also an :accept form field, with the same value as the
>>> HTTP header, in case it is proven that setting the HTTP header does
>>> not work in some browsers
>>
>> I have a patch for this ready at
>> https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12446912
>>
>> Here's how it's implemented:
>> 1. A class JSONResponse which extends HtmlResponse (for backward compatibility)
>> 2. A class MediaRangeList for parsing the HTTP Accept header
>> 3. A method SlingPostServlet.createHtmlResponse for determining which
>> format (HTML/JSON) to return to the client
>>
>> The JSON format is kept as close to the HTML format as possible.
>>
>> JSON is only returned if the client sends "application/json" in the
>> Accept header, with a greater preference than text/html. Also, the
>> Accept header can be simulated by a the :http-equiv-accept query
>> parameter.
>> I dropped the automatic return of JSON on JSON posts (SLING-1172) - I
>> think the client should specify application/json in Accept anyway, if
>> it wants JSON returned.
>>
>> WDYT? Is this a sensible way of implementing this?
>
> It hink this is basically a good idea. Esp. having the overwrite parameter.
>
> Though for symmetry with GET requests, where the .json extension ask for
> a JSON response, we might want to also support this for POST ... Don't
> have a very string preference, though.
Yes, I think we have been discussing this before. The problem is, what
if you want to post to a JSON file (e.g.
http://localhost:8080/content/file.json)?
You probably want a JSON response in those cases too, but I fear this
could become inconsistent.
Also, strictly speaking, the Accept header will probably say that the
client prefers a text/html response (which is what web browsers do as
default). So, to strictly comply with RFC 2616 [1], we should return
HTML when we're able to, and the client has not specified a preference
for something else.
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070
Re: Let SlingPostServlet return JSON (WAS: Re: Client JSon Calls)
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 08.03.2010 09:08, Vidar Ramdal wrote:
> On Thu, Jan 28, 2010 at 3:10 PM, Vidar Ramdal <vi...@idium.no> wrote:
>> Finally, we implement the logic for choosing either sendHtml() or
>> sendJson(), based on:
>> 1. The format of the posted data - if JSON is posted (SLING-1172),
>> return JSON, otherwise return HTML
>> 2. The Accept HTTP header - if set to "application/json" return JSON,
>> otherwise return HTML
>> 3. Possibly also an :accept form field, with the same value as the
>> HTTP header, in case it is proven that setting the HTTP header does
>> not work in some browsers
>
> I have a patch for this ready at
> https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12446912
>
> Here's how it's implemented:
> 1. A class JSONResponse which extends HtmlResponse (for backward compatibility)
> 2. A class MediaRangeList for parsing the HTTP Accept header
> 3. A method SlingPostServlet.createHtmlResponse for determining which
> format (HTML/JSON) to return to the client
>
> The JSON format is kept as close to the HTML format as possible.
>
> JSON is only returned if the client sends "application/json" in the
> Accept header, with a greater preference than text/html. Also, the
> Accept header can be simulated by a the :http-equiv-accept query
> parameter.
> I dropped the automatic return of JSON on JSON posts (SLING-1172) - I
> think the client should specify application/json in Accept anyway, if
> it wants JSON returned.
>
> WDYT? Is this a sensible way of implementing this?
It hink this is basically a good idea. Esp. having the overwrite parameter.
Though for symmetry with GET requests, where the .json extension ask for
a JSON response, we might want to also support this for POST ... Don't
have a very string preference, though.
Regards
Felix