I want to make a request to this url https://api.uber.com/v1.2/requests/{request_id}/receipt, but I don't know where I get this request_id. Somebody knows?
You would get the request ID from posting a request. More information can be found on making a request here: https://developer.uber.com/docs/riders/references/api/v1.2/requests-post
So the trip flow goes: your app makes a request on behalf of a user, you receive a request ID. After the trip is completed you would the call that URL you specified to provide/get a receipt for that trip.
Related
I made a request to verify the purchase token by referring to the official materials, but error message "{responseCode 8 , responseMessage ERROR_INVALID_PAYMENTTOKEN}" was returned. The URL of the request API was {rootUrl}/applications/purchases/tokens/verify. Is there anyone who can help me with this problem?
First, you need to make sure that consuming or confirming a product is performed for a user only when the user has successfully purchased it, that is already owned the product.
Then you also need to ensure that the input parameters in the API call request are correct.
For example,use the wrong site to check that purchaseToken.or The productID is not added to the PMS or is incorrect. and so on.
For more details,you can refer to error codes.
I redirect the user to a page with the Smart Payment Buttons passing the order id in the URL
example.site?orderid=D23F34492211
But if the user changes the URL, the JavaScript will fetch an id that doesn't exist. Eventually, the transaction will not be completed, however, it will just close the PayPal's lightbox as well as the credit card option, without giving any error message.
The error it throws is something as following:
Fatal error: Uncaught PayPalHttp\HttpException: {"name":"RESOURCE_NOT_FOUND","details":[{"issue":"INVALID_RESOURCE_ID","description":"Specified resource ID does not exist. Please check the resource ID and try again."}],"message":"The specified resource does not exist.","debug_id":"9d62d83a871b8","links":
Is there any way to get this response as JSON or get the error code from the API and show an error message to the user? If not, what's the best way to verify whether the order id exists or not?
You shouldn't be passing the order ID via a URL, you should be fetching it from your server. Then you will know it is valid.
Anyway, your question is bout verifying the status of an order ID via an API call. It is not necessary to do this. You should not have to do this. But if you insist on doing it, there is an API call you can use. https://developer.paypal.com/docs/api/orders/v2/#orders_get
This API call should be run from your server, so if you want to call it from the client, you will need to build a middleware endpoint route on your server. (Again, there is no point to doing this and it would be wasted effort)
The actual proper way to do things is to fetch the order ID from your server, as mentioned: https://developer.paypal.com/demo/checkout/#/pattern/server
I am having trouble naming rest endpoints for my otp service.
Here I have 4 endpoints, in brackets I have given inputs
SEND API (Mo. No.) - Generates OTP and send to mobile number, in response it gives TransactionId
RESEND API (TransId) - Resend same OTP to mobile Number with the transactionId
VERIFY API (OTP, TransId)- Verify if the OTP given for the transactionId, is correct to what is stored in cache
ISVERIFIED API (TransId) - Check whether particular transactionId is verified or not
Can anyone please tell me how should I make REST endpoints for these APIs, adhere-ring to REST principles of resources, etc.
I thought of
POST v1/sendOTP
POST v1/resendOTP
POST v1/verifyOTP
POST v1/isVerifiedTransaction
Obviously, this is not a good design of endpoints, I need some help
Better approach would be
POST v1/send-otp
POST v1/resend-otp
POST v1/verify-otp
POST v1/is-verified-transaction if you have to make the separate endpoint for each
else as these can be part of the same end-point only the payload can be different, you cna do something like
POST v1/otp?action=send
POST v1/otp?action=re-send
POST v1/otp?action=verify
POST v1/is-verified-transaction or v1/transaction?status=is-verified
Maybe you should have otp and transaction as resources and do something like this:
POST v1/otp/send
POST v1/transaction/{transId}/resend
GET v1/transaction/{transactionId}/verify?otp={otpId}
GET v1/transaction/{trandId}/isVerified
I am not sure how otp and transactions relate, so it might be a bit off, just throwing the idea of having them as resources
I'm trying to build a simple Email Verification API. Below you can find the expected client requests in order:
The client gets an email address as an input. (e.g. mail#example.com)
The client sends a request: GET /emails/?email=mail#example.com
If mail#example.com has not been created before, meaning the previous request returns an empty list as a response, it sends a request: POST /emails/ where email#example.com is in the request body parameters.
The client sends a request: POST /email-verifications/ with email_id in the request body and creates a new email verification object. Upon successful creation, the client receives a token in the response body and 6-digit verification code is sent to the corresponding email address.
Now the client gets verification code as an input from the user.
The client sends a request: PATCH /email-verifications/id/ with token and code in the request body.
I'm not exactly sure about the last step since the corresponding update operation receives two inputs as token and code that won't be updated in the instance. Rather, they will be compared with the existing instance and upon success another field is_verified will be updated.
Is this a right way to implement such operation? Or are there any better practices that I can follow?
PATCH is often not the perfect fit for things, and I think that you probably also shouldn't be using it here.
We've ran into a similar issue as you did and wondered how to design it. In our example it wasn't a token and code but it was an API for changing a users password.
Also in our case, a client would send a new password to a server but the server would never return the password.
The most appropriate solution for us ended up being a special password resource, with a url like:
/users/x/password
A GET request on this url would always yield a 403, and only a PUT request will be supported here. I kinda have the feeling that your design problem should be solved the same way.
I am using Graph API of facebook to read user's messages.
https://developers.facebook.com/tools/explorer?method=GET&path=me%2Finbox
To get the access token, I have selected 'read_mailbox' permission.
On submitting the request, I get the response as JSON string, but the response does not contain first message of the conversation.
What am I missing?
Thanks and Regards,
Arjabh
You missed nothing. The Facebook Graph API returns a thread with all messages. You will need read the parameter "unread" and after parse the JSON content, get the last X ("unread") messages of the thread. They are the unread messages.