Develop Reference

Is it correct to send a 401 error before the user tries to login?

In a REST Api i'm developing, someone told me to directly send a request to the "get current user (/me)" url without checking if there is a session token and simply redirect him to the login page when receiving a 401 response.
Is this correct? I thought that the browser should not receive a 4xx response unless the user does something he is not supposed to.

I thought that the browser should not receive a 4xx response unless the user does something he is not supposed to.
That's more restrictive than described by the standard, see RFC 7231
The 4xx (Client Error) class of status code indicates that the client seems to have erred.
The server can't distinguish errors by the user from errors by the user agent - there's just a single HTTP request, that has to be judged of itself.
Another way of expressing the same idea: REST's uniform interface constraint implies that clients with human users should be getting the same self descriptive responses as clients without human users.

We do exactly this. We basically send a HTTP request, and if it comes back as a 401, we know we need to log the user in.
We also send a Link header to tell the client where the user should go for log in:
HTTP/1.1 401 Unauthorized
Link: </login>; rel="authenticate"

Handling get response while server has been crashed

I have a question.
I send a Get request by Ajax every second and expect to get some response from the server.
In the case and my application crashes and I continue to send Get request every second, I don't get any response until receiving the server's timeout error (an error code 502.) .
If somebody knows how I can handle this moment between sending the get requests every second and until receiving error code 502.
Thanks

If the server is down, whatever you are using for the ajax call should have errored out... in which case you should handle it with a call back or a catch block. There, you should handle what you will do on the frontend based on the response.
As far as not sending out more requests, there really is no way to know for sure. For all your code knows, the server is particularly slow at that moment.

Process reponse data when getting a non HTTP 2xx answer with appAPI.request

I'm using appAPI.request to make ajax calls to an external web API. This works very well, but the API sends HTTP status codes other than 200 when something goes wrong. It also sends the error message/code when this happens. As the onFailure callback does only returns the http error code, but not the response message, i'm unable to read the error message sent by the server. Is there any way to retrieve the response message when onFailure gets called?

As of now, the HTTP response text is not currently available in the onFailure callback. However, as we are constantly working on improvements, we will add this to our API in future releases.
Disclaimer: I am a Crossrider employee

Is it possible to execute custom code in every Ajax request without having manually add that code to every ajax code in Ext Js?

If user is logged in, then ajax requests work fine. When session is invalidated, ajax returns login screen and user can see login screens as ajax content. Is it possible to add custom code in Ext Js, that would be run every ajax request, to check if session is still valid, if session is not valid, then JavaScript would redirect to login page, otherwise it would continue execution Ajax request normally.

Ext.ajax is a singleton, so you can define a global handler for all request errors.
Your server side code will need to return a HTTP 403 or simmilar if the user is not authorised. Put this somewhere (only once) in your code code:
Ext.Ajax.on('requestexception', function(conn, response, options) {
if (response.status == 403) {
Ext.MessageBox.alert('Authentication', 'You are not logged in.');
/* you can display a login box or something here */
}
};
If an AJAX request fails because the session has expired, you can handle it gracefully in your code.
The options argument contains the AJAX request options, so if you present your user with a login box and reauthenticate them, you can resubmit the original AJAX request they were making automatically. The process should be seamless for all the rest of your existing code thats making AJAX requests.

Checking whether the session is still valid should be done in the server. Not in JavaScript.
We do not trust clients.

You could modify your ajax process in two ways:
1- server end: on receiving a request, check session - if user not logged in or session expired, return an HHTP 403 (=not authorised).
2- client end: as part of your ajax response handler, check for error 403. If it is returned, ask for login and send that to server, then when login has been successful, resend orginal request.
That's easy if you're not using too many ready-made ajax libraries. If you are, look to its functionality.

Using HTTP status codes to reflect success/failure of Web service request?

I'm implementing a Web service that returns a JSON-encoded payload. If the service call fails -- say, due to invalid parameters -- a JSON-encoded error is returned. I'm unsure, however, what HTTP status code should be returned in that situation.
On one hand, it seems like HTTP status codes are for HTTP: even though an application error is being returned, the HTTP transfer itself was successful, suggesting a 200 OK response.
On the other hand, a RESTful approach would seem to suggest that if the caller is attempting to post to a resource, and the JSON parameters of the request are invalid somehow, that a 400 Bad Request is appropriate.
I'm using Prototype on the client side, which has a nice mechanism for automatically dispatching to different callbacks based on HTTP status code (onSuccess and onFailure), so I'm tempted to use status codes to indicate service success or failure, but I'd be interested to hear if anyone has opinions or experience with common practice in this matter.
Thanks!

http status code are just for indicating the status of the application response.
and as you said, if json parameters as somehow invalid, a 400 status code is an appropriate answer.
so yes, it is a really good idea to use http status code. de plus, status code are then easy to understand as they don't change from an application (web services) to another

You should definitely use the proper status codes since they are exactly for this purpose, not to indicate the status of the HTTP request itself. By this way you can redirect the response to the appropriate function/branch before parsing it which will lead to a much tidier code in the client side.