I am writting REST API now. I faced with one problem - how 404 page in api should look like.
Of course it will be better to show user link to the API documentation.
But what about page in general.
Should it be beautiful page or just simple text also in JSON or XML format.
If page has a lot of images/scripts, we have to use network connection inefficiently.
Surely, we can get only headers of http response but it seems to be bad solution.
I have looked on several well-known APIs and the way how do they implement 404 pages.
Both Flickr and Twitter has 404 pages with some images, css.
But Github has pretty simple response, just JSON with following content.
{
"message": "Not Found",
"documentation_url": "https://developer.github.com/v3"
}
I think this is good example of response (without images and css) if not please correct me.
So my question is what is the best practice for the 404 API response, should it be pretty simple (like on GitHub) or it is better to add some other useful information about API.
Thanks everyone in advance.
If someone request an API they will most likely catch the 404 exception and look for the HttpStatusCode. If it's 404 they don't need more information and just report that the User (?) is not found.
So it doesn't really matter what you do as 99% of the request won't even download the response site
A 404 Not Found response in an API is not required to have any content at all. The client code will probably look at the status code before it looks at the content of the request.
Every REST client code I've written so far does not concern itself with the body of a 404 Not Found response. I can not imagine anything in the body that has any use above the fact that the resource was not found.
Related
I am having a problem making a request to the Banno Plugin I do not have this issue when the "View More" section is clicked. I belive that I have found the issue but looks like I cannot reach out to banno directly so wanted to see if there is anyone that has seen this issue.
When reaching out to the auth "a/consumer/api/v0/oidc/auth" endpoint I have assigned claims to the payload
{"userinfo":{"address":null,"birthdate":null}}
But when reviewing the error request I get a invalid_request could not parse claims parameter request on the claim but the claim is no longer the claim I gave it and is injecting /a/consumer/api to the first json object like below:
{"userinfo":{"address":/a/consumer/api,"birthdate":null}}
When I use the Card Action to this external application it works as expected but while in the plugin card it fails due to the parsed claim.
Any feedback would be helpful?
Out of curiosity, are you URL encoding the characters claims payload?
The example you've given:
{"userinfo":{"address":null,"birthdate":null}}
...would look like this once it is encoded:
%7B%22userinfo%22%3A%7B%22address%22%3Anull%2C%22birthdate%22%3Anull%7D%7D
I am trying to scrape this website
scraping website
I have analyzed all the XHR files and found that https://stock360.hkej.com/data/getQuotes/00002?t=1583900958659 is the data fetching site, but I have difficulties in accessing through chrome directly. It return me unknown host found:
Can anyone explain to me what happening deal with this HTTP GET call. I understand that 00002 is the stock number and t is the time
Seems like the endpoint requires a specific header for it to work.
I found that it requires referer header with value of https://stock360.hkej.com/quotePlus/stockFinancialStatements/1
Here's the example request i sent from Postman:
I am working on a JSON project and I basically want to hit on some specified URL with some request and get the response back. I want to know if there are some sites available that can provide me help for request, response on JSON?
Any sort of help is welcome!
Back when "Ajax" was being coined (and well before), we often used the XML HTTP Request object (W3 Schools) but web development is more mature now. Libraries such as jQuery wrap this functionality for easy use (jQuery Ajax)
I'm trying to find the correct HTTP status code for a page where the content is temporary unavailable however there is no redirect, instead a message is displayed on the page informing the user the content is temporarily unavailable.
307 Temporary Redirect isn't applicable as there is no redirect.
404 Not Found might possibly be applicable, however I'm not sure if this is the correct response to give as the content is found, just not available.
410 Gone isn't applicable as the content will be available again some time in the future.
None of the other codes seemed even remotely applicable. Does anyone know the correct code to use and can explain why?
It sounds like the 4XX series of responses are appropriate here. From the RFC:
The 4xx class of status code is intended for cases 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.
With this in mind, I think 403 forbidden is the most appropriate:
10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated.
If the request method was not HEAD and the server wishes to make
public why the request has not been fulfilled, it SHOULD describe the
reason for the refusal in the entity. If the server does not wish to
make this information available to the client, the status code 404
(Not Found) can be used instead.
I suggest this for three reasons:
It's not an exotic code, so it will work fine in the browser. This, to me, is the most important reason - you will be able to serve a page that explains why the content isn't available, and you can be fairly certain it will be displayed correctly.
It's appropriate for the server to say "I understand your request, but I won't serve you that content at this time", and that's exactly what the first two lines of the description say.
It doesn't explicity say "forget you ever knew about this content" to any robots (or for that matter, people).
For completeness, here's why I ruled out the other response code categories:
2XX Success: This class of status code indicates that the client's request was
successfully received, understood, and accepted.
But, we're not accepting the request in this case. I don't think 2XX is right.
3XX Redirection: This class of status code indicates that further action needs to be
taken by the user agent in order to fulfill the request.
I suppose that you could argue "further action" to mean "please wait until the content is available before trying again", but reading the other 3XX codes, "further action" usually means "immediate redirect", which as you've already pointed out, isn't appropriate.
5XX Server error: Response status codes beginning with the digit "5" indicate cases in
which the server is aware that it has erred or is incapable of
performing the request.
Nothing has gone wrong on the server, you just don't want to serve the content right now.
HTTP STATUS CODE 204
i.e. NO CONTENT
Read More about it here:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
section 10.2.5
i.e.
The server successfully processed the request, but is not returning any content.
What is the best practice with regard to sending error responses in a JSON web service? I have seen it done several ways and wanted to know whether there were any agreed-upon standards or best practices among the choices.
I've seen it done where the response includes indication of success or failure as well as the data to be returned or a suitable error message, e.g.
[{'success':true, 'data':{...}]
[{'success':false, 'data':{'message':'error'}]
But I've also seen examples where the JSON object only includes data, and the service uses the normal HTTP error codes to indicate a problem (403, 404, 500, etc). (This is how the Twitter API does it.)
Is there a "right" way to do this, or is it just a matter of style? Is the latter method more "RESTful?"
In a "RESTful" approach, the primary error response is indicated by an appropriate status code (4xx/5xx).
Your message should provide addtional, application-specific hints on how to recover from the error. This may include human-readable representations of the error that has occured or some kind of more technical indicator (i.e. providing an Exception class name).
For being generic, keep to a fix syntax for your error messages. This allows you to introduce new error messages withour breaking the clients.
Use the appropriate HTTP codes and put what you now call "data" as the body of the response. This is the only correcty RESTful way to make the API users aware of an error.
Just doing this will not make your API RESTful, but not doing it will surely make your API non RESTful.
An example of well-used HTTP status codes for errors is in the Dropbox v1 API reference, have a look at the "Errors" sections under each method, they explain which error codes you should expect and what is the associated meaning in that particular method.