I'm using Next redirect object which allows redirecting (inside getServerSideProps), and trying to understand what status code is returned in response.
The only hint I found in the documentation is:
In some rare cases, you might need to assign a custom status code for
older HTTP clients to properly redirect.
So what status code is returned by default with this implementation? There are multiple code relevant to redirecting (301, 302, 307 and more), and I found conflicting claims in the web.
Here's a list of the possible status codes that Next.js will return based on what happens in the process of server-side rendering:
https://github.com/vercel/next.js/blob/db9040b0b85b6e111543de516961e0249faaf0e8/packages/next/pages/_error.tsx#L5
const statusCodes = {
400: 'Bad Request',
404: 'This page could not be found',
405: 'Method Not Allowed',
500: 'Internal Server Error',
}
You can also specify your own statusCode prop as part of returning an error/redirect from Next.js.
EDIT: Adding from #juliomalves, the default status codes are 307 (permanent: false) and 308 (permanent: true) for redirect!
Related
When making a POST, PUT, PATCH request with badly formed body (e.g. wrong types, missing required fields) to an unknown endpoint, should that return 404 or 400?
Example:
There exists an endpoint /resource/:resourceId.
There exists a resource with resourcedId: 1.
Endpoint requires 2 fields for PUT request. enable: boolean and count: number.
Client makes the following request PUT /resource/2 with body { enable: 7 }.
Should the server return 404 (because resource with resourceId: 2 does not exist) or 400 (because body is in invalid format)?
The first check you should make is whether the request launched by your client is well formed.
If it's not well-formed, you should return a 400 Bad Request Error, preventing it from going beyond your controller.
In case the request is well formed, you allow it to access your business logic layer and if it does not find the resource it is looking for (in your case the '2') then you must return a 404 Not Found Error.
In case of doubt, you have a lot of documentation about HTTP codes, I leave you for example this documentation from wikipedia
HTTP codes
im currently working on a website which has Spring at backend and Angularjs at front side and we had discussed about back end responses to handle frontend's message dialogs and i have a question to ask:
Lets say i have an API :
GET : /getstatistics
Request params : fromTime,toTime ( in timestamp format)
And if client make a request with invalid params like a string, which response code should be returned from server ? HTTP 400 bad request and response body with a message " fromTime and toTime should be in timestamp format" or HTTP 200 with same message?
I saw some Google's APIs for example Oauth, they're returning code 200 for a request with invalid access_token but ,in our project my opinion it should be HTTP 400 because Javascript has success and error callbacks, is it better for it just pop a red color dialog with message inside rather than a HTTP 200 code then still need to check the content of the message?
Any advides and opinions are appreciated.
Thanks!
You should be returning a 400 error for bad request. Check out this reference.
The server cannot or will not process the request due to something
that is perceived to be a client error (e.g., malformed request
syntax, invalid request message framing, or deceptive request
routing).
Please have a look at RFC7231#section-6
A client MUST understand the class of any status code, as indicated by
the first digit
and,
4xx (Client Error): The request contains bad syntax or cannot be
fulfilled
Bad syntax can be something like you've mentioned in your question (making a request with invalid parameters, like a string).
I keep these two references handy whenever I'm designing RESTful APIs, might be helpful for you too:
https://httpstatuses.com/
http://www.restapitutorial.com/httpstatuscodes.html
Yes you are right, the http code should be 400 in your case. Your discussion here normally should be whether you need to return 400 or 422. For this you can check the accepted response for this SO question 400 vs 422 response to POST of data
I think it has something to do with how the parameters are used. If you use the resource, then a 404 should return. If the data is simply not valid then we decide to set a 409 Status to the request. It can't full fill it at 100% because of missing/invalid parameter.
HTTP Status Code "409 Conflict" was for us a good try because it's
definition require to include enough information for the user to
recognize the source of the conflict.
Reference: w3.org/Protocols/
Edit:
In any case, the status code 200 is incorrect here because there is an error. In response, you can then return specific information like this:
{
"errors": [
{
"userMessage": "Sorry, the parameter xxx is not valid",
"internalMessage": "Invalid Time",
"code": 34,
"more info": "http://localhost/"
}
]
}
I have
/rest/drink/categories?alcohol=true
which is return 200 status code with list of drink categories that have alcohol in it, e.g.
200 ['wine','beer']
I wonder what status code should I use, if a user hit a none handled path like below
/rest/drink
or
/rest/drink?alcohol=true
404 - Not found if the URL does not exist,
400 - Bad request if the URL exists but the request parameter is invalid.
Http has status for such conditions.
4XX defines the error is from client side and needs a change.
Wiki says
The 4xx class of status code is intended for situations in which the client seems to have erred. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents should display any included entity to the user.[31]
For the condition where it is mentioned, its ideal to use 404 - Not Found or 400 - Bad Request
This gives list of all the status codes and appropriate explanation.
W3Org
defined the specifications for these.
Let's say I have a REST POST end-point: www.foo.com/id/X where X represents a number.
My server-side pseudocode looks like this:
performIdLookup(int id) {
if ( idExists(id) ) {
return toJson(lookup(id)) // returns 200/OK Status Code with object as JSON
}
else {
return HTTP_???_error
}
}
Per this question, sending a 400 error doesn't seem right here since the user submitted a valid request, but the server couldn't locate it.
What's the right HTTP response here and why?
That is very easy.
404 Not Found
If there is no resourece at /id/42, a resource can not be found for this URL.
See the list of HTTP status codes.
Not 400 (bad request). But 404 (not found). Yes, 404 is not what we are used to watching in these cases, but you can add some custom information with response.
When a client invokes my REST-ful service, it needs to know if the response came back was 'from me' or rather a diagnosis from the containing web server that something awful happened.
One theory is that, if my code is called, it should always return an HTTP OK(=200), and any errors I've got to return should be just represented in the data I return. After all, it's my code that gets the response, not the naked browser.
Somewhat self-evidently, if I'm using REST to generate HTML read directly by a browser, I absolutely must return an error code if there's an error. In the case I care about, it's always Javascript or Java that is interpreting the entrails of the response.
Another possibility is that there is some family of HTTP status codes that I could return with a high confidence that it/they would never be generated by a problem in the surrounding container. Is this the case?
I use the following:
GET
200 OK
400 Bad Request (when input criteria not correct)
POST
202 Accepted (returned by authorization method)
401 Unauthorized (also returned by authorization)
201 Created (when creating a new resource; I also set the location header)
400 Bad Request (when data for creating new entity is invalid or transaction rollback)
PUT
Same as POST
201 Ok
400 Bad Request
DELETE
200 OK
404 Not Found (same as GET)
I would not know how to avoid that some container returns codes like 404.
4xx codes are meant to handle client errors along with possibly some entity that describes the problem in detail (and thus would mean a combination of both of your mentioned approaches). Since REST relies on HTTP and the according semantics of status as well as methods, always returning 200 in any possible case is a violation of this principle in my opinion.
If you for instance have a request such as http://foo.com/bar/123 which represents a bar ressource with id=123 and you return 200 with some content, the client has no chance to figure out if this was the intended response or some sort of error that occured. Therefore one should try to map error conditions to status codes as discussed in REST: Mapping application errors to HTTP Status codes for example.