I've tried calling the balanced.js card.create() with an address with including one of the test postal codes or test street addresses included in the api in the function call but the object I get back does not include an avs_street_match or avs_postal_match object.
As mentioned on https://docs.balancedpayments.com/1.1/overview/resources/, validation of cards does not occur until an authenticated operation is performed against it. Those fields are not part of the tokenization response, but rather are part of the Card response from an authenticated operation against it. Something like a GET on the href returned in the tokenization response would provide a Card response with the fields you mention.
Related
Hi Im working on a REST API for a e-commerce app and had a couple questions about which are the correct URNs to map some specific actions, having in mind the definition of URI stated on RFC 3986: A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.
The action of sharing a post which receives an email and shares the post url via mail. Specific posts are mapped to /api/posts/id which is correct. The thing is I don't know how to map the URL of this action. A post to an URI like /api/posts/id/share is totally incorrect by definition of URI considering that share is an action and not a resource.
The action of resetting your password and the action of asking for a password reset email. Users are mapped to /api/users. Something like /api/users/password-reset-email and /api/users/password-reset would be incorrect following the same guideline explained before.
The key takeaway from the dissertation that introduced REST is:
Any information that can be named can be a resource...
Have a look at Resources and Resource Identifiers for more information.
In other words, an action is a resource.
In your own words, a URI is a sequence of characters that identifies an "abstract or physical resource". Just because an action doesn't easily map to a tangible object doesn't make it less of a resource.
There are status codes which only exist to respond to 'actions' (e.g. 202 Accepted).
All in all, POST /api/posts/{id}/share seems completely reasonable.
POST is really there as a 'catch all' for actions. In RFC2616 it says the "function performed by the POST method is determined by the server" and the function performed "might not result in a resource that can be identified by a URI".
The main points:
An 'action' should almost always involve POST
The 'action' performed should relate to the URI and body of the POST request.
You should return an appropriate status code (e.g. 200, 201, 202, 204, 4xx).
I'm building an API. When requesting the data of a user this is shown to be the best practice to retrieve the data:
Requests user data with ID:
https://api.example.com/users/1
However it would be more convenient to requests user data with their email:
https://api.example.com/users/johnsmith#outlook.com
Is it safe to use the second method? Even if I was to use the first method, there is no way that a developer would know the ID for the user which they would like to request, so it would not be useful at all.
So is the second method safe? If not, is there a solution? Thanks.
As long as the ID is unique and parsable in the URI. The '#' would need to be encoded into a "%40". Other than that its fine, IMHO. If you have two different types of identifiers, like email and ID then you might want to allow a client to select which identifier to use
https://api.example.com/users?email=johnsmith#outlook.com
or
https://api.example.com/users?id=1
Here is some good literature for how to use filters in REST API's.
Passing email address in URL is not a good idea as it is non-public information. If you really need to go with email address then go with POST call or you can use id which is completely safe if you are using proper authorization at API end.
Imagine a simple REST API that allows to create a user account, by sending a JSON resource to POST /users as in the following. By default it sends out a confirmation email to the user.
{
"username": "john#appleseed.com",
"password": "secret"
}
However sometimes there are good reasons for not sending out a confirmation based on the use case, e.g. another API client, or admins signing up users on their behalf.
Since it doesn't have any implications on the created resource but is more of an instruction how to create the user, should it be separate from the request body? What's the best way to do this?
Specify a custom header Confirmation: no-confirmation
Add a query param ?confirmation=false
Add a send_confirmation field to the request body
Let's take the options in order:
Adding a header value to indicate some semantic difference should be generally avoided. The API should be "browseable", meaning it should be discoverable following links only.
Adding a query parameter is, from REST perspective completely equal to creating another URI. It does not really matter how you expose it, the point is that the client needs to follow some links from the previous "state" it was in. This is actually ok, as long as the links to these resources indicate the different semantics you described: like creating users by admin, users creating themselves, etc.
Also note, that the API should not necessarily expose whether a confirmation is sent. The API should expose the "purpose", the server then can decide whether the use-case warrants a confirmation email.
Putting a send_confirmation in the JSON representation itself. This is ok, if this is a functionality available for the user. For example I can ask for a confirmation email. If I can't, and it is only used for differentiating different use-cases, then I would rather prefer option 2.
Summary: For the case you are describing I would pick option 2: different resources for admins and normal users.
I am designing the APIs for the backend of my app.
Suppose the user can follow the activity of another user.
In this case, I designed an API which allow me to do:
POST /me/following
and the id as body for this request.
Then I can retrieve the list of followers in this way:
GET /me/following
This API comes with pagination, so I cannot retrieve the entire list at once.
But how can I check if the user follows another user? Should I use something like
GET /me/following/{user_id}
and check the status code for this request? Like 200 it exists or 404 it doesn't exists in the list?
Usually 404 means the endpoint called doesn't exists. What if the entity doesn't exists? Is there a status code for that?
GET /me/following/{user_id} seems good.
I would probably return a 204 No Content :
Successful 2xx
This class of status code indicates that the client's request was successfully received, understood, and accepted.
[...]
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.
404 in contrast describes some kind of error, though it could do the job as well depending how you look at it
Client Error 4xx
The 4xx class of status code is intended for cases in which the client
seems to have erred.
404 Not Found
The server has not found anything matching the Request-URI. No
indication is given of whether the condition is temporary or
permanent.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
Many sites with registration that ask email confirmation and sites use tokens in their url.
Why do they use it?
For example in case of email confirmation: why just not use registered user id instead of token?! In case of using it in web pages, i didn't get at all!!
Explanation with real applications would be appreciated!
Thanks in advance!
A token in this context is typically a disposable time-limited random string used for verification. A token of (say) 40 characters can be generated easily [such as sha1(microtime() . rand(1, 10000)))], which isn't guessable by the user and isn't brute-forceable (within reason).
For email verification, a token will be generated and linked with your account ID. When you visit the address containing the token, the account gets activated. Since we've established that a token can't be brute-forced or guessed (within reason), we've just established that a certain user does indeed have the email address they gave us.
If we just used their member number, they could do several things to just guess it, thus bypassing the email check entirely.
When logging in or submitting a form of some kind, the term "token" may be used in a slightly different context - it's still a disposable time-limited random string, but it's used to make sure that the person who submitted the form has just come from the form they tried to submit.
For example, say you log into your online banking. They might have a form to transfer money to another bank account. If you go to www.nastysite.com they might include an iframe that points to <iframe src="http://www.mybank.com/send_money.php?amount=9001&to=Joe">. If your bank don't verify that you were actually on the form, that payment will go through, and you won't be best happy. Even if you are on the form, the chances of the correct token on your form being used in the fake page-load are (almost) nil.
This is called "Cross-Site Request Forgery", or CSRF. For some more reading on CSRF, have a look at this Wikipedia article. Also, I've just got that link after writing this post and seen that they use a very similar example to mine - genuine coincidence haha.