This adds support for the GET method (and technically all methods, it doesn't matter).
The endpoint now redirects to the referrer if specified in the headers (Referer) with query strings: message and topics.
It also responds with JSON only if there is an Accept header with either of:
application/json
text/json
In all other cases, it responds with HTML.
Things not done: the message is always returned in the message query string (or JSON key) even for errors. The status code denotes if it was an error (500 or 400). The only exception is the redirection which always returns 302 in which case the caller does not know if there was an error. We could add a new parameter (error: true|false) to cover this case, but it won't cover cases where the AWS stack returns 500, so I'd rather ignore this minor case which only happens if the client does not support JS and receives an error.
@hammady Can we remove the check for */* in the Accept header? The HTML form element includes this in the request headers, and it's not possible to change those for form elements :(
This adds support for the GET method (and technically all methods, it doesn't matter). The endpoint now redirects to the referrer if specified in the headers (
Referer
) with query strings:message
andtopics
. It also responds with JSON only if there is anAccept
header with either of:application/json
text/json
In all other cases, it responds with HTML.
Things not done: the message is always returned in the
message
query string (or JSON key) even for errors. The status code denotes if it was an error (500 or 400). The only exception is the redirection which always returns 302 in which case the caller does not know if there was an error. We could add a new parameter (error: true|false
) to cover this case, but it won't cover cases where the AWS stack returns 500, so I'd rather ignore this minor case which only happens if the client does not support JS and receives an error.