We are using SharePoint 2016 for storage and retrieval of files. And using java httpclient class to do it. Now we are using following API to check whether folder is already present.
String folderURI = "/_api/Web/GetFolderByServerRelativeUrl('" + "/<document library/folderpath>" + "')";
e.g : folderpath = test1/type/2007
Following is the code to contact SharePoint and get it's response.
HttpGet httpget = new HttpGet(finalURL);
httpget.setHeader("Content-Type", "application/octet-stream");
httpget.setHeader("X-HTTP-Method", requestMethod);
httpget.setHeader("Cookie", "rtFa="YqLvkl";FedAuth="uZnxt");
response = httpClient.execute((HttpUriRequest) httpget);
If the folder already present, I'm getting 200 ok as response, which is correct. But if folder not present, I'm getting 500 internal server error. instead of this,I should get 404 Not Found. What am I missing. how come for the same API, I'm getting one correct response(folder present 200 ok) and one internal server error(folder not present 500).
4xx errors are client errors; 5xx errors are server errors.
4xx errors mean you (the client) have made a mistake with the way you submitted your request. 5xx errors mean the server failed to fulfill an apparently valid request.
A response of 404 (Page Not Found) would indicate that the requested URI is itself invalid/doesn't currently exist. This would make sense as a response if you were trying to access the direct path of a folder that doesn't exist (instead of invoking a web service through the /_api/Web/ URI).
Your requested URI is a valid web service call, so 404 Not Found would be not be an appropriate response.
500 (Internal Server Error) is the generic response that indicates that the web server ran into an error while attempting to perform an operation.
In this case the error is caused by the web service attempting to retrieve a folder that does not exist.
Related
I'm trying to develop error handling in my REST API and I'm currently working on the response codes. I haven't found a proper answer to what would be the appropriate response code for my problem.
I have routes which are managed like this in the back-end code:
$site->route([
'route' => '/{id:^[a-z]+$}'
]);
Now lets say the user inputs www.example.com/page1 which does not match the regex pattern. What would be the correct response? I am thinking either a 404, page not found, but I also think that a 400 response would be correct, because it describes that there was an error with the request.
I already use 404 if static URLs are invalid, so this is a question of matching dynamic parts of the URLs.
What are the field of use of both of these response codes in the case of REST APIs?
I think 404 is more appropriate.
According to the specification, 400 means:
The 400 (Bad Request) status code indicates that the server cannot or
will not process the request due to something that is perceived to be
a client error.
While 404 means:
The 404 (Not Found) status code indicates that the origin server did
not find a current representation for the target resource or is not
willing to disclose that one exists.
From client point of view, request to /page1 will result in error, because the resource page1 does not exist (no route is matched in server side).
Normally, 400 means the server has already targeted the resource, but cannot return that resource due to client error. In this scenario, server cannot target the resource if no route is matched. Anyway, if the request is sent to /123456 and the status code is 400, what should be the error message? "Your requested URL is incorrect" sounds like 404, and "Your requested URL should follow regular expression: ...^[a-z]+$..." sounds very weird.
RFC 2616 says 502 means: "The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request."
What exactly counts as an invalid response? Does this include something like a 500 from the upstream server?
Imagine that you have implemented and API that aggregates responses from a couple of third party servers. E.g. you have an application that if asked for info about lol#lol.com user will return all the public data about this user from FB, TW and G+.
More or less your API acts as a proxy server. Now if one of these requests fails you have a choice what will be returned to the client. If you want to be explicit about how your application works you can return 502 Bad Gateway along with message: Sorry, request to FB failed for whatever reason and that's all. But you can also hide the implementation details and return a e.g. 409 Conflict response along with details: Have no info about the user's FB activity.
In this particular example 207 Multi Status would be also very useful.
Scenario:
A POST request is sent to process an order that will result in data retrieval from an external datasource.
There are three possible results:
The datasource returned data for the request
No data was available for the request (this is viewed as an error)
The datasource couldn't be accessed (may be down for maintenance)
An obvious response for 1 is 200: OK or 201: Created (an entity is created from this request).
What status codes would be appropriate for 2 and 3?
Status codes I have considered:
503: Service Unavailable when datasource is down
500: Internal Server Error when datasource is down
502: Bad Gateway when "no data available"
404: Not Found when "no data available"
403: Forbidden when "no data available"
412: Precondition Failed when "no data available"
2) Looking back at this, I agree it should probably be either a 204 No Content or maybe a 200 with a body indicating no records or resources could be found depending on the structure returned.
404's are generally used when the resource URI doesn't exist or a resource in the URI is not found in the case of a restful service.
3) 503 Service Unavailable
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.
Note: The existence of the 503 status code does not imply that a
server must use it when becoming overloaded. Some servers may wish
to simply refuse the connection.
3) I agree with 503 for this
2) Frankly I think a good argument could be made for using 204 in case 2 You can include metainfo in the header to indicate specifically what 'went wrong'. It really depends on how much you consider this case to be 'an error' at the API level.
If the API itself is functioning as intended, and the request was to a valid endpoint, by an authenticated and authorized user and did not cause the server to malfunction, then very few of the 400 or 500 series errors would really seem to apply.
for example, 404 usually means the URI you called does not exist, if it does exist, then using that code is misleading at least IMHO
**10.2.5 204 No Content**
The server has fulfilled the request but does not need to return an
entity-body, and might want to return updated metainformation. The
response MAY include new or updated metainformation in the form of
entity-headers, which if present SHOULD be associated with the
requested variant.
If the client is a user agent, it SHOULD NOT change its document view
from that which caused the request to be sent. This response is
primarily intended to allow input for actions to take place without
causing a change to the user agent's active document view, although
any new or updated metainformation SHOULD be applied to the document
currently in the user agent's active view.
The 204 response MUST NOT include a message-body, and thus is always
terminated by the first empty line after the header fields.
HTTP 404 - With your own error message like "No data found".
Twitter uses 404.
Reference: https://developer.twitter.com/en/docs/basics/response-codes.html
The datasource returned data for the request
200: OK/201: CREATED
Because everything is working as expected
No data was available for the request (this is viewed as an error)
400: BAD REQUEST
The request was invalid or cannot be otherwise served. An accompanying error message will explain further inside the body.like:
HTTP 400
{
response: null,
code: "USER_101", //should be used customized error codes here
error: "User details not found"
}
The datasource couldn't be accessed (may be down for maintenance)
404: Resource/URI NOT FOUND
The URI requested or resource is invalid
Like: https://www.lipsum.com/list-page
**/list-page** is not defined/found
Find here most frequently used status codes:
200 – OK
Everything is working, The resource has been fetched and is transmitted in the message body.
201 – CREATED
A new resource has been created
204 – NO CONTENT
The resource was successfully deleted, no response body
304 – NOT MODIFIED
This is used for caching purposes. It tells the client that the response has not been modified, so the client can continue to use the same cached version of the response.
400 – BAD REQUEST
The request was invalid or cannot be served. The exact error should be explained in the error payload.
401 – UNAUTHORIZED
The request requires user authentication.
403 – FORBIDDEN
The server understood the request but is refusing it or the access is not allowed.
404 – NOT FOUND
There is no resource behind the URI.
500 – INTERNAL SERVER ERROR API
If an error occurs in the global catch blog, the stack trace should be logged and not returned as a response.
In my opinion the best way to handle this is with a 200 no result object.
Why?
You have a response that you can do something with without a lot of trouble. I searched, everything worked correctly but there wasn't anything in the database to give a result. Therefore, result = null and a message explaining as much. If something found this in the network calls it is not a security risk.
If you are concerned with a security risk then a 204 is probably the best approach.
res.status(200).send({
result: null,
message: 'No result'
});
What HTTP status should I return if my script throws an exception?
200 OK
or
500 Internal Server Error
Let's say user request parameters are correct but there is a bug in my script which causes an error message to appear instead of a proper response (XML, JSON or other format). What should be the HTTP status?
500 Internal Server Error is the correct status if the error can't be fixed by the client changing their request.
Use any of the 4XX statuses if the client might be able to fix their request to avoid the error (or 404 if the resource wasn't found).
200 OK is not the appropriate status in almost any error situation, because then the client thinks things are running normally (which they are not) and may continue to make the same error-causing requests.
Familiarize yourself with the available status codes in RFC2616 and find one that most appropriately fits the situation.
It depends on why the exception is thrown since they can be used for almost any error. If it's thrown because some id in the URI is not found in the database I'd say 404. On the other hand if it's because the database is down I would throw a 500. If an exception is thrown but the resulting page would still be useful to the user I would say return 200.
Review the Status Code Definitions. 500 or 400 should do for general issues, however, the more detailed you can be then the more useful the returned status will be.
How do you communicate an error to the web service consumer ?
For example, my web service has a function to insert employee into db.Suppose while inserting the data , the database gave an error,what should be the best way to inform the user about the error.
One way is to depict it through the return value of the web service method but what to do when the function is supposed to return a complex object like employee when there is no error ,and will send an error string when there is an error ?
For SOAP: That is what faults are used for
SOAP faults are used to carry error information within a SOAP message. The fault is for SOAP what an exception is for a programming language.
When your client's request succeeds, you send back a valid response with the Employee structure, when it fails, you send back a fault with details of what went wrong.
For REST: Use HTTP Error Codes
Unlike SOAP, REST web services do not have a convention for returning errors but the simplest is to use the ones everybody understands.
For example you might send a HTTP 404 Not Found when a record is missing, a HTTP 500 Server Error when something happend on the database etc, and return HTTP 200 OK with your result when everything is fine and dandy.