I'm trying to remove a due date from a task using the following request:
curl --request PUT -u <KEY>: https://app.asana.com/api/1.0/tasks/<TASKID> -d "due_on=null"
and receive
{"errors":[{"message":"due_on: Day must be in yyyy-mm-dd format, not: null"}]}
What's the correct way to do it?
(I work at Asana)
This is supposed to work - it appears to be a bug. This should be fixed in our push today (11/20/2012). Thanks for reporting the problem!
Generally, in the API there are some fields which can take on the value of null in the JSON. When you use form-urlencoded parameters instead of a JSON content type, none of the values have specific types - they all come in as strings. In some places we weren't consistent about treating the string "null" as a real null value where it makes sense, like for due dates.
Related
First you must know I'm a total beginner, I'm trying to learn so I almost don't know anything.
On the basic page of the API, there is a curl command used as an example to show us how to make requests.
I'm using Ruby on Rails so I used "curl-to-ruby" website to translate it, but it did not work as expected.
I wanted it to show me this :
uri = URI.parse("REQUEST_URL")
response = JSON.parse(Net::HTTP.get(uri))
Instead I got this :
uri = URI.parse("REQUEST_URL")
response = Net:HTTP.get_response(uri)
I don't understand any of this, I thought I wouldn't need to and just use "curl-to-ruby", but apparently I really need to get this.
Would you please try to explain me ?
Or give me links ?
Or matters to read (curl, API, http) ?
Thank you very much, have a nice day.
It's because that command doesn't return just the content, it returns the whole HTTP response object including headers and body. You need to extract the response body and parse that using JSON.parse(), e.g.
JSON.parse(response.body)
See documentation here: https://docs.ruby-lang.org/en/2.0.0/Net/HTTP.html#method-c-get_response
(Also, there is nothing in the cURL command which would hint to the converter that the content-type of the response was expected to be JSON (e.g. perhaps an "accepts" header or something), so even if it were able to produce extra code adding the JSON.parse part, it has no way of knowing that it would be appropriate to do so in this case.)
If I follow the instructions at this website, the first two (profile.txt and profile.json) should return a .json profile object. Instead I am just getting an output of raw numbers. This was working a few weeks ago so I'm unsure what has changed?
https://console.bluemix.net/docs/services/personality-insights/getting-started.html#getting-started-tutorial
So it turns out for whatever reason, it is returning the raw text values by default, NOT the structured JSON file as specified in the tutorial. An issue has been raised, however in the meantime you can simply add:
--header "Accept: application/json"
This will ensure you get the structured json file.
When notification is passed to the app after payumoney processing it sends response hash and we need to compute the hash and match it with the passed in response hash.
I use the following code to compute the expected response hash.
Digest::SHA512.hexdigest([
PAYU_SALT,
notification.transaction_status,
notification.user_defined,
notification.customer_email,
notification.customer_first_name,
notification.product_info,
notification.gross,
notification.invoice,
PAYU_KEY].join("|"))
The hash of the following string is computed
"salt|success|||||||||||||Payment|100.0|1|key"
When I print the following hash it gives
Digest::SHA512.hexdigest([
PAYU_SALT,
notification.transaction_status,
notification.user_defined,
notification.customer_email,
notification.customer_first_name,
notification.product_info,
notification.gross,
notification.invoice,
PAYU_KEY].join("|"))
#⇒ e7b3c5ba00b98aad9186a5e6eea65028a[...]
whereas notification.checksum gives
#⇒ 546f5d23e0cadad2d4158911ef72f095d[...]
So the two hashes don’t match.
I am using the following gem: https://github.com/payu-india/payuindia
I appreciate any help as to why the response hash is not matching. Is there any error in my logic to compute the response hash? Thanks!
Where did you come up with that order for the fields in the array?
Looking at PayU's Developer FAQ it seems like the order is the following:
key|txnid|amount|productinfo|firstname|email|||||||||||salt
Please make sure that the hash is calculated in the following format - hashSequence= key|txnid|amount|productinfo|firstname|email|udf1|udf2|udf3|udf4|udf5||||||salt
Please make sure that in the above sequence please use the UDFs which have also been posted to our server. In case you haven't posted any UDFs, the hash sequence should look like this - hashSequence= key|txnid|amount|productinfo|firstname|email|||||||||||salt.
Keep in mind that when computing the hash even a single character out of place will result in a completely different checksum.
little late but Actual Sequence is:
SALT|status||||||udf5|udf4|udf3|udf2|udf1|email|firstname|productinfo|amount|txnid|key
Thanks to Ravi Kant Singh
but additionalCharges| are removed
Tested with live environment
Check your hash in above order and if its match you can process request
ok this was a silly mistake i made. The reason the hash didn't match was beacuse i had a typo with the PAYU test key. At the end i typed small 'u' when it was 'U'. The library is fine and the logic is right. The error was in my side with using wrong key.
Actual Sequence for hash is :
additionalCharges|SALT|status||||||udf5|udf4|udf3|udf2|udf1|email|firstname|productinfo|amount|txnid|key
Actual hash generation for additional charges:
additionalCharges|SALT|status||||||udf5|udf4|udf3|udf2|udf1|email|firstname|productinfo|amount|txnid|key
Without additional charges:
SALT|status||||||udf5|udf4|udf3|udf2|udf1|email|firstname|productinfo|amount|txnid|key
I am trying to pass multiple values for a parameter in a POST request body as follows
var1=1&var2=2&var34=3,4&var5=5
I've tried several ways to pass var34 as a string of values 3 and 4 but still not working. Need some help.
Thanks!!!
This isn't really a question about Fiddler, so it's not clear what you're asking specifically.
The server interprets POST data according to its own rules, and there's no standard for handling duplicate name/values in urlencoded data.
Some servers would accept var1=1&var2=2&var34=3,4&var5=5 as you've used, while some would prefer var1=1&var2=2&var34=3&var34=4&var5=5.
What error or problem are you encountering?
It turns out that it's the server (I use R) side that I need to adjust the codes to accommodate the POST request. It has nothing to do with the request. Thank you so much for the suggestion!
I'm attempting to retrieve the "shares" graph data for a number of pages in JSON format. I suspect that the errors I am encountering stem from the fact that some of the URLs have commas in them, and are being parsed as an attempt to pass multiple ids.
Returns graph data.
https://graph.facebook.com/?ids=http://celebritybabies.people.com/2012/08/23/backstreet-boys-howie-dorough-expecting-second-son/
Returns error 2500 "Cannot specify an empty identifier"
https://graph.facebook.com/?ids=http://www.people.com/people/article/0,,20624518,00.html
Encode the commas, still returns 2500
https://graph.facebook.com/?ids=http://www.people.com.people.article/0%2C%2C20624518%2C00.html
There doesn't seem to a way around it other than to use the normal inspection
http://graph.facebook.com/http://www.people.com/people/article/0,,20624518,00.html
You may have to file a bug at http://developers.facebook.com/bugs though I feel as the answer would most likely be "Status by design".
You could try using FQL instead, querying the link_stat table:
SELECT url, normalized_url, share_count, comments_fbid FROM link_stat
WHERE url = 'http://www.people.com/people/article/0,,20624518,00.html'
(See result in Graph API Explorer.) You can also use WHERE url IN ("…", "…", …) to check multiple URLs at once.
This also returns a comments_fbid of 10151022112466453, and that one you can look up via the API, https://graph.facebook.com/10151022112466453
Maybe this can work as a workaround, until Facebook fixes this problem.