Hi,
Am 29.04.2008 um 13:41 schrieb Tobias Bocanegra:
and there will be another request parameter
which allows to override the response code for special case handling
like hidden iframes in forms. This parameter could be named
sling:post:responseCodeOverride and the value could be the response
code that should be used. If the parameter is not present the real
response code will be send.
and what do you do if you create and modify and delete several
resources at the same time? what response code do you send?
OK, that's indeed a problem I which I have not considered so far.
I rather suggest we define a parameter, which will be used as a
flag -
for example :ignoreStatus - whether the real response code is
expected
(such as 201, 404, etc.) or a 200 response containing the intended
response code.
And I think the default behaviour (in the absence of this flag) is to
use the real response code and only send a 200 response (for iframe
support) in case of the flag being present and set.
i think it's the opposite (see below). that the normal case 1) is the
most natural and this could not respond with 201, or something.
there are 3 use cases of the post servlet:
1) Normal HTML forms that users fill in content they want to store in
the repository. imo, this is mostly the case for normal apps like
blogs, wiki, application forms, shopping carts, etc.
I agree that (1) is the most likely use case, for (2) and (3) I think
the order is debatable. Haven't tried it but is it really a problem
for the browser if it receives a 201? What happens in that case?
2) Special HTML form handling in hidden frames that are used by
frameworks that have 'dialogs'.
3) XHR requests for ajax apps
the desired responses are quite different though:
1) wants a redirect to the edited or created content after the post.
2) wants a human/machine (browser) readable response. that's why we've
chosen an XHTML response that can easily be accessed though the DOM in
javascript.
3) wants probably a json response that easily can be transformed into
an object structure in javascript.
we could include a flag that indicates the desired response:
:responseType="xml"
:responseType="json"
where "xml" is the default and always responds with a 200.
where "json" is a json representation of the response and also uses
the correct response codes.
What about using extensions to specify the desired behaviour?
This could look as follows:
POST to /foo -> 200 OK and a XHTML representation
POST to /foo.html -> 200 OK and a XHTML representation
POST to /foo.xml -> correct response codes and a XML
representation
POST to /foo.json -> correct response codes and a JSON representation
For the first case I'm unsure if it would be better to send correct
response codes, header fields and a XHTML. Changing the behaviour here
would break existing clients and thus all of them must be changed.
Regards,
Alex
