With the new request id system request id are composed of 2 parts, the request id and the user id. The documentation
says you must delete the request id using the full id of the request but if the user has no accepted the application you can't have his id? Before when you accessed to the request you have a to field containing information about the user but now it's gone if the user haven't accepted the application?
So my question how access to the user id if he hasn't accepted the application? It clearly express that we need to delete the request but without the user id it can't be done).
I'm having the same issue in my own app. I've submitted a bug report since there doesn't seem to be any way of doing so (even though the Javascript SDK seems like it should work at first glance) https://developers.facebook.com/bugs/239476836116522
Related
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
How does doing the same post request twice create duplicate for the same resource.
From what I learnt and understood,
whenever someone does
POST api/users/reg
I must register the user and create the resource URL for the specific user.
Now if someone tries to register with same data on the given api, how is it supposed to create a duplicate resource. It would respond with an error showing that the username is already taken.
Rethink your API design. The resource type users may have many users with unique resource id.
api/users/reg/:userId
This way you can post any number of users given the id is different each time.
This could be a duplicate of here and here, but can some one provide a complete working example for following.
I have set of different Facebook account Ids, and i need to get the respective account details(user name etc) from these account ids. I need to send a Batch Request for Graph API. Something as follows,
(https://graph.facebook.com?ids=user1, user2, user3,...)
Is this possible as pure HTTP GET request ?
I am using Facebook SDK with Android for the moment. I have gone through the API doc but unable to build the required query yet. Please help.
Maybe post a snippet of your code so we can try to solve your problem better. With the info you provided, the URL https://graph.facebook.com/?ids=user1,user2,user3 works just fine and returns 3 users.
The URL format looks correct. Keep in mind the total character limit, but otherwise I suspect you are stuck in a different place (e.g. sending the query or saving the result).
I am creating a way people can connect their Fb, Twitter and FS account to the account they create on my application. I wanna create a single table where i can store all the required stuff..
User(id, username, password, email)
Oauth (id, user_id, oauth_provider, ....... )
As for my Understanding
Facebook needs facebook id
Twitter needs id, token, secret
Foursquare requires email and consumer id.
Just wanted to confirm i am doing it right.. in constructing the Oauth Table.
I personally create a field named "setting_parameter" for the requirement's value because all of these API need different things. As you've said Facebook need App ID (plus Token), Twitter needs Consumer Key and consumer Secret..
All of this value I merge them all into one string with JSON-format. I don't put them each into the field because I think there won't be necessary for me to query this table for operations other than get their value. Beside, I need to implemented other APIs in the future. That's why I can't create special field, because I won't know what kind of value the new API will going to need next time. That's why I prefer to squished them into one string field.
The table of mine is like this
Oauth(id, name, setting_parameter, description,...)
I've implemented an iPhone App that uses a RESTful HTTP POST to register itself with a web server via Rails.
Some time later, the App needs to update its own record on the server, and so needs to know the id of its own record for the RESTful HTTP PUT path.
However, the App was never told the id of its own record on the web server resulting from the POST. So, it then needs to search for it on the server using the device's UDID (stored in the record), return the corresponding id, and then construct a RESTful URL based on that... this all seems rather cumbersome.
Is there a more elegant design-pattern for this? (it would be convenient if the original POST returned some data that allowed me to obtain the record id, but it doesn't seem to).
Thanks.
To close this question off, the answer, which was supplied by Oscar Del Ben above, is that it is indeed necessary to find the record using some other unique key e.g. UDID, and update that record with a POST once retrieved.
(of course, the POST also returns the created record, with id, so it could be saved that way, if the design allows)