I am building an API on NodeJS and I would like to use the correct HTTP returns for the created interfaces. I am using the placements indicated on the sites:
My question:
I built the "checkEmail" API with ajax. The page calls the server, which checks whether the email entered by the user exists or not. Theoretically, when a resource is not found, I should return a 404. If the email does not exist, I return a 404 - which in this case is a success for the user (he can use this email). However, if an email exists, I return a 200. This, for purposes of the screen, returns an error because the email is already in use and the user will have to enter another one. The last case would be if the user entered an invalid email. In this case I return a 500, stating that the content you entered is not a valid email.
Is this logic correct? I am in doubt as I am using 404 for success (in this case) and 200 for failure (email found - already used).
Thanks.
500 should used for server errors only (Like an internal exception) where as 400 errors imply client error such as invalid input. For invalid email, that would be a 400 family since the client could change the input email and it may succeed.
For an object that doesn't exist in a database, there is a debate on whether it should be a 20x or a 404. I personally don't like 404 just for missing objects in a database for an API since it could also look like the route doesn't exist. (i.e. I types in /user/1234 instead of userS/1234 when the routes was defined as /users/{id}. Most frameworks now have a 404 catch all if the route template doesn't exist which may need my attention. Same goes for reverse proxies in the middle that could be routing to different API servers. I like knowing from a quick glance if the route template is correct and that the object is just doesn't exist in a Db.
So this brings up which 200. You could use 204 (No Content), which means the body doesn't have any content (But that doesn't imply the database doesn't). Many use this for a DELETE which doesn't return the deleted object back. 204 has more meaning in browsers rather than a pure AJAX API, but it definitly works. You could also use just a plan 200.
500 is used for server error and 40- for user errors i suggest 200 for bot cases found and not but changing body result
Related
I'm using MongoDB for my Express app and I know that when an ID is an invalid ID for the corresponding database, the response status code is 400 (Bad Request). But what if the ID is a valid ID but there's no document with that ID (for example the document might be deleted)? I'm guessing the status code should be 404 but I'm not sure, what are your opinions?
What should the response status code be in a REST API when the given ID is a valid ID but there's no matching document?
404
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.
If you need to communicate why you are returning a 404, that's done in the body of the response:
the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition.
Why not 204?
Primarily because that's not what 204 is for:
The 204 response allows a server to indicate that the action has been successfully applied to the target resource, while implying that the user agent does not need to traverse away from its current "document view" (if any).
For a GET request, the appropriate way to signal that the current representation is 0 bytes long is a 200 response with a Content-Length field.
That said, the origin server has the freedom to decide for itself whether the absence of a document with the right id means there is no current representation, or if the current representation is empty. In other words, the existence of "documents" at the origin server is an implementation detail that is hidden behind the web facade.
I am really new to node js and trying to integrate Paypal's Payment Gateway into my application.
Upon the success of the payment, the user is redirected to http://localhost:3000/success?paymentId=PAYID-M8MU148234F&token=EC-2111Y&PayerID=YX82JX6Q where our code executes the order and return a payment object (contains order details).
On this page, I want to display the order details to the user.
I want to store the payment object as a JSON.stringify into my Mongoose database for future reference. The issue is that if the user keeps on reloading this page, the code inside app.get('/success'..) will keep on adding the same columns to the mongoose database repeatedly. I am not sure how to prevent that.
Since the payment is actually executed only when this URL is visited by the user, multiple reloads by the user blocks me from Paypal API and gives me the following error:
response: {
name: 'MAX_NUMBER_OF_PAYMENT_ATTEMPTS_EXCEEDED',
message: 'You have exceeded the maximum number of 20 payment attempts.',
information_link: 'https://developer.paypal.com/docs/api/payments/#errors',..........
The only solution I can think of right now is that somehow my /success route executes the payment and stores the data onto the database and then redirects the user to maybe /someOtherPage/ page with the order details as headers. I am not sure how to make this redirect happen and also pass some context (the payment object) at the same time.
You are using a deprecated v1/payments API and/or PayPal-Node-SDK. You should change your integration to the current v2/checkout/orders and Checkout-NodeJS-SDK.
Make two routes on your server, one for 'Create Order' and one for 'Capture Order', documented here. These routes should return only JSON data (no HTML or text). The latter one should (on success) store the payment details in your database before it does the return (particularly purchase_units[0].payments.captures[0].id, the PayPal transaction ID)
Pair those two routes with the following approval flow: https://developer.paypal.com/demo/checkout/#/pattern/server
The above mostly takes care of this issue and is the recommended solution, as it does not rely on redirects and gives an improved user experience that increases buyer confidence by keeping your site loaded in the background. But to more directly address the issue posed here: when doing an execute or capture API call, set the PayPal-Request-Id HTTP header to something that will persist across retries that are not expected to result in new actions/transactions -- for example simply set this header to the PAYID or OrderId being acted on. This will give idempotent behavior (see API idempotency)
The Bing Web Search API worked last week and at some point this week, it has been returning 403 errors. I don't know if anyone else has been encountering similar problems?
To replicate this, simply signup here with a bing account and you should get 5000 free queries per month. Below is a snippet of code (I believe I'm properly authenticated since putting in improper credentials fails gives a 401, rather than 403 error).
import requests
user = '...'
key = '...'
# 403 error
requests.get('https://api.datamarket.azure.com/Bing/Search/Web?Query=%27Xbox%27&$format=json', auth=(user, key))
# 401 error
requests.get('https://api.datamarket.azure.com/Bing/Search/Web?Query=%27Xbox%27&$format=json', auth=('a', 'b'))
Is anyone else getting this?
403 is the Forbidden status code. Your subscription probably expired or you exhausted your query limit.
Server errors are always in the 500-599 range. Errors in the 400-499 range are always client errors. If you repeatedly receive 500 errors, you should check Azure's status page to ensure there isn't a problem.
As a rule, you shouldn't assume that a major service like Bing Search is down and no-one noticed for days. It's far more likely that there is a problem with your account or your code, especially if you receive client error codes.
This endpoint on Spotify's Web Api throws a 500 error for the username "spotify":
GET https://api.spotify.com/v1/users/{user_id}/playlists
Is this intentional on Spotify's end? Does Spotify not wants developers to access its playlists.
Note - All other usernames work fine
A 500 error should always be treated as being unintentional. If the server side wants to limit access a response code in the 400 range should be used instead, like 403 or possibly 401. It is likely that there are so many different public playlists for the Spotify account that one of them has triggered a bug. If for some reason the error code 500 is intentional, it is still a bug, but in the API, which should be fixed.
I work at Spotify, but don't have direct access to this system. I will let people know.
My server returns a 403 forbidden error when a user tries to access a resource that they do not have access to. Along with the header the server also writes a small message describing the error.
In Firefox the error message gets displayed nicely and the user knows what's going on.
In Internet Explorer the message is hidden and replaced with the 403 Forbidden standard error page.
Are there any specific rules that allow me to display an error message across all browsers while still setting the status to 403 Forbidden?
Here is the RFC info on this status:
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.
It seems like I should be setting a message but IE just won't display it.
Try making your 403 page larger (i.e. more bytes). Some browsers assume that a short error page is the default page from the web server and decide to show their own, presumably more helpful text.
More info.
The implementation of error handling is browser dependent. In HTTP if you are just going to return a 403 error then you have to rely on the user agent (the technical name for the browser, the recipient of your error message may not be a browser) to handle out how it sees fit.
If you don't like how the browsers are handling 403 errors and want to ensure a consistent user experience across all browsers then redirect the user to your own 'permission denied' page. You can build a page that can explain to them why permission was denied and what they might be able to do about it. And it will be consistent for any browser.