You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Vidar Ramdal <vi...@idium.no> on 2010/01/27 11:21:19 UTC
Let SlingPostServlet return JSON (WAS: Re: Client JSon Calls)
(Continuing this discussion on dev@sling.apache.org - started at
http://n3.nabble.com/Client-JSon-Calls-td139540.html#a139540)
> On Wed, Jan 27, 2010 at 10:21, Vidar Ramdal <vi...@idium.no> wrote:
>> It would be nice if there was a way to get JSON output from the
>> standard SlngPostServlet, so that way we could leverage current
>> SlingPostOperations. I have looked into it briefly. The HtmlResponse
>> object that is passed to SlingPostOperations is a bit of a turn-off in
>> this sense, but AFAICT only HtmlResponse.send() actually produces
>> HTML.
>> We could abstract HtmlResponse to some output-agnostic Response
>> object, and then let SlingPostServlet decide (how?) which output
>> format to return.
On Wed, Jan 27, 2010 at 11:00 AM, Alexander Klimetschek
<ak...@day.com> wrote:
> That would be a good idea. The return format should be selected via
> the extension (POST foobar.html vs. POST foobar.json).
Ah yes, but I think we've been down that road before. What if I
actually want to post to a node called /foobar.json
(node.getName().equals("foobar.json"))?
Maybe we could use the Accept header from the request [1] instead - if
the client wants JSON (by specifying application/json in Accept), let
it have JSON - if not, return HTML.
> But some background on the html response: The reason why it was chosen
> is because it is the only response that works, ie. that is parseable
> by a javascript browser client, when you post a form to the
> SlingPostServlet via a hidden iframe (to post forms in an ajax style
> _and_ support file uploads). With an iframe, the response cannot be
> json, but only html. The structured html of the sling html response
> allows you to parse out the message, status, etc.
True, but since the HtmlResponse template is not XML, it's not easily
dealt with in e.g. dojo.xhrPost() response handlers.
> So in the end, the usable combinations for the SlingPostServlet will
> probably be:
> form post => html response
> json post => json response
But if we look for the Accept header (and perhaps also an equivalent
request parameter, like :accept), shouldn't we be able to determine
response type regardless of form post type?
[1] http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z3
--
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
Re: Let SlingPostServlet return JSON (WAS: Re: Client JSon Calls)
Posted by Vidar Ramdal <vi...@idium.no>.
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 Vidar Ramdal <vi...@idium.no>.
On Wed, Jan 27, 2010 at 12:53 PM, Vidar Ramdal <vi...@idium.no> wrote:
> HtmlResponse is in the exported in o.a.s.api.servlets, so we probably
> can't mess around with it a lot, for backward compatibility.
> The HtmlResponse.send() method is public, but I guess it is intended
> for use only from SlingPostServlet?
>
> I suggest we deprecate HtmlResponse, and create a subclass of it
> called, say, PostResponse. "Subclassing" to create a more generic
> class sounds weird, but I'm not sure how we otherwise could preserve
> compatibility.
>
> The HtmlResponse.send() is deprecated, and its functionality moved to
> SlingPostServlet as sendHtml(). We also introduce
> SlingPostServlet.sendJson().
> 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
Filed this as https://issues.apache.org/jira/browse/SLING-1336
--
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 Vidar Ramdal <vi...@idium.no>.
>> Maybe we could use the Accept header from the request [1] instead - if
>> the client wants JSON (by specifying application/json in Accept), let
>> it have JSON - if not, return HTML.
On Wed, Jan 27, 2010 at 12:08 PM, Alexander Klimetschek
<ak...@day.com> wrote:
> Yes. Is it possible to set the Accept header for XHRs in all browsers?
> (I guess yes, but these kinds of things really have to be tested ;-))
Definately needs to be tested, yes :)
>>> But some background on the html response: The reason why it was chosen
>>> is because it is the only response that works, ie. that is parseable
>>> by a javascript browser client, when you post a form to the
>>> SlingPostServlet via a hidden iframe (to post forms in an ajax style
>>> _and_ support file uploads). With an iframe, the response cannot be
>>> json, but only html. The structured html of the sling html response
>>> allows you to parse out the message, status, etc.
>>
>> True, but since the HtmlResponse template is not XML, it's not easily
>> dealt with in e.g. dojo.xhrPost() response handlers.
> [...]
> The returned HTML is parsed for you by the browser
> and the dom can easily be traversed to extract the various fields.
When rendering the result in an IFRAME, yes, but not (AFAIK) when the
HTML is returned in an XmlHttpRequest response body.
(Side note: Could we modify HtmlResponse.html ever so slightly, so
that it as least is XHTML? That would make processing it from a
XmlHttpRequest response body much easier.)
HtmlResponse is in the exported in o.a.s.api.servlets, so we probably
can't mess around with it a lot, for backward compatibility.
The HtmlResponse.send() method is public, but I guess it is intended
for use only from SlingPostServlet?
I suggest we deprecate HtmlResponse, and create a subclass of it
called, say, PostResponse. "Subclassing" to create a more generic
class sounds weird, but I'm not sure how we otherwise could preserve
compatibility.
The HtmlResponse.send() is deprecated, and its functionality moved to
SlingPostServlet as sendHtml(). We also introduce
SlingPostServlet.sendJson().
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
Does this make any sense at all?
>>> So in the end, the usable combinations for the SlingPostServlet will
>>> probably be:
>>> form post => html response
>>> json post => json response
>>
>> But if we look for the Accept header (and perhaps also an equivalent
>> request parameter, like :accept), shouldn't we be able to determine
>> response type regardless of form post type?
>
> Right, I wasn't really suggesting to bake in these fixed combinations,
> I was just guessing what will be typical in the end. Parsing XML/HTML
> in xhr response for example is unnecessary because JSON is much
> simpler.
>
> So maybe we use the type of the request body as the default, then look
> at the Accept header. I think we should only introduce an :accept
> field, if the Accept header doesn't work for all cases.
Sounds good.
> Also, if we want to support JSON posts, we need some thinking about
> it: it allows for more structure than the form post with a flat list
> of fields and one might want to make it look like the json returned
> from the json get servlet to allow for round trips. The sling json
> content loader mechanism (used upon bundle installation) might be used
> for that. Although that is a somewhat separate discussion for
> https://issues.apache.org/jira/browse/SLING-1172
Yes, processing JSON posts is a totally different issue, in my opinion.
--
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 Alexander Klimetschek <ak...@day.com>.
On Wed, Jan 27, 2010 at 11:21, Vidar Ramdal <vi...@idium.no> wrote:
> Ah yes, but I think we've been down that road before. What if I
> actually want to post to a node called /foobar.json
> (node.getName().equals("foobar.json"))?
Ok, that might be an issue then.
> Maybe we could use the Accept header from the request [1] instead - if
> the client wants JSON (by specifying application/json in Accept), let
> it have JSON - if not, return HTML.
Yes. Is it possible to set the Accept header for XHRs in all browsers?
(I guess yes, but these kinds of things really have to be tested ;-))
>> But some background on the html response: The reason why it was chosen
>> is because it is the only response that works, ie. that is parseable
>> by a javascript browser client, when you post a form to the
>> SlingPostServlet via a hidden iframe (to post forms in an ajax style
>> _and_ support file uploads). With an iframe, the response cannot be
>> json, but only html. The structured html of the sling html response
>> allows you to parse out the message, status, etc.
>
> True, but since the HtmlResponse template is not XML, it's not easily
> dealt with in e.g. dojo.xhrPost() response handlers.
Yes, and other responses should be possible for pure XHR and/or
non-browser HTTP clients. I was simply talking about the full scope
with in-browser forms that include file uploads - these have to be
multi-part form encoded, and you can't do this with XHR, only with
iframes. Therefor this was chosen as the default mechanism for the
sling post servlet. The returned HTML is parsed for you by the browser
and the dom can easily be traversed to extract the various fields.
But yes, its a not so pretty workaround. Support for simpler
request/response body formats is a good thing.
>> So in the end, the usable combinations for the SlingPostServlet will
>> probably be:
>> form post => html response
>> json post => json response
>
> But if we look for the Accept header (and perhaps also an equivalent
> request parameter, like :accept), shouldn't we be able to determine
> response type regardless of form post type?
Right, I wasn't really suggesting to bake in these fixed combinations,
I was just guessing what will be typical in the end. Parsing XML/HTML
in xhr response for example is unnecessary because JSON is much
simpler.
So maybe we use the type of the request body as the default, then look
at the Accept header. I think we should only introduce an :accept
field, if the Accept header doesn't work for all cases.
Also, if we want to support JSON posts, we need some thinking about
it: it allows for more structure than the form post with a flat list
of fields and one might want to make it look like the json returned
from the json get servlet to allow for round trips. The sling json
content loader mechanism (used upon bundle installation) might be used
for that. Although that is a somewhat separate discussion for
https://issues.apache.org/jira/browse/SLING-1172
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Let SlingPostServlet return JSON (WAS: Re: Client JSon Calls)
Posted by Alexander Klimetschek <ak...@day.com>.
On Wed, Jan 27, 2010 at 11:21, Vidar Ramdal <vi...@idium.no> wrote:
> Ah yes, but I think we've been down that road before. What if I
> actually want to post to a node called /foobar.json
> (node.getName().equals("foobar.json"))?
Ok, that might be an issue then.
> Maybe we could use the Accept header from the request [1] instead - if
> the client wants JSON (by specifying application/json in Accept), let
> it have JSON - if not, return HTML.
Yes. Is it possible to set the Accept header for XHRs in all browsers?
(I guess yes, but these kinds of things really have to be tested ;-))
>> But some background on the html response: The reason why it was chosen
>> is because it is the only response that works, ie. that is parseable
>> by a javascript browser client, when you post a form to the
>> SlingPostServlet via a hidden iframe (to post forms in an ajax style
>> _and_ support file uploads). With an iframe, the response cannot be
>> json, but only html. The structured html of the sling html response
>> allows you to parse out the message, status, etc.
>
> True, but since the HtmlResponse template is not XML, it's not easily
> dealt with in e.g. dojo.xhrPost() response handlers.
Yes, and other responses should be possible for pure XHR and/or
non-browser HTTP clients. I was simply talking about the full scope
with in-browser forms that include file uploads - these have to be
multi-part form encoded, and you can't do this with XHR, only with
iframes. Therefor this was chosen as the default mechanism for the
sling post servlet. The returned HTML is parsed for you by the browser
and the dom can easily be traversed to extract the various fields.
But yes, its a not so pretty workaround. Support for simpler
request/response body formats is a good thing.
>> So in the end, the usable combinations for the SlingPostServlet will
>> probably be:
>> form post => html response
>> json post => json response
>
> But if we look for the Accept header (and perhaps also an equivalent
> request parameter, like :accept), shouldn't we be able to determine
> response type regardless of form post type?
Right, I wasn't really suggesting to bake in these fixed combinations,
I was just guessing what will be typical in the end. Parsing XML/HTML
in xhr response for example is unnecessary because JSON is much
simpler.
So maybe we use the type of the request body as the default, then look
at the Accept header. I think we should only introduce an :accept
field, if the Accept header doesn't work for all cases.
Also, if we want to support JSON posts, we need some thinking about
it: it allows for more structure than the form post with a flat list
of fields and one might want to make it look like the json returned
from the json get servlet to allow for round trips. The sling json
content loader mechanism (used upon bundle installation) might be used
for that. Although that is a somewhat separate discussion for
https://issues.apache.org/jira/browse/SLING-1172
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com