I have a web-hook that calls an API that returns a single plain text response. The response isn't formatted in JSON or xml because the response is a single piece of data, not a map or array. I see plenty of examples of how to extract a field from a JSON response and store it in a marketo token but no example of how to store the whole response payload. Here is a sample response from the API:
alsdfjasdhfalksdhfalksdjalksdk
Note that the response is not anything like this:
{
"field":"alsdfjasdhfalksdhfalksdjalksdk"
}
Maybe some Marketo expert has done this and could share. I'd appreciate it, thanks.
Marketo's parsing of XML and JSON is limited, to say the least--so your webhook does need to declare some sort of key-value pair so the response can be mapped. Given what you're describing, you could likely just hardcode in the surrounding JSON with the right MIME type and be fine.
Basically, Marketo can only handle the following for JSON webhook responses:
Key-value pair
Key can only be defined by placement (no XPath or similar--you'd be stuck with field[1] or similar)
Ideally no nesting, as Marketo doesn't do a great job of reading nested data--largely for the reason mentioned above
Related
I debugged some of Facebook's internal endpoints and I found a wired response payload.It contains a for loop and JSON blob, why and what could you do with this loop?
Endpoint:
https://www.facebook.com/ajax/bootloader-endpoint/?modules=PagesCometHeaderActionsMenuWrapper.react&__user=100015575597279&__a=1&__dyn=7AzHK4HwBgC265Q2m3m8GEnxenFw9uu2i5U4e2O14xtoK3q322aewXwnEboG4E6icwJwpUe8hw8u1_w5nCxS320LE36xOfwwwto88hwKx-8wgolzUOm0Z84a3aUS2G2CaCzU7W8wnolwBgK7qwpE31wLxG4UaoC9xy48aU8od8-Uqxy1qxi4UaEW1-xS6FobrwKxm5oe8aU&__csr=i-ABExfiGWDGZmGJ5ybF2krpA9OeahlWQhhebaFUwFqZ34Xy9nNydnV11KyVaiE8CBx7b5PPi4nqiu-QFBbmjO5BllBeLIgWDiGyGWx2-ZrG8VF39KuG8jyLb8hqyuHo-nluKAuG-iiboGuad_BAmiOCoB5ja4ohyHF3SEqzoRqHBxm8wNCxqagF3Q2KPVpcGWB8Qcc8Fabj9O3R8Z2ol1jBh5XBxhy8hhGh9A9gl8i4W8FGvzUybyXgnoBaEJyJUqz6VWHYyjC8qidAAQozTF27KjCxCb89aFEw89rJeFQEvG46kx8hpEz9HgEEACA9xumgN8C9l4xfxG48jx6q4XwOwXp8lCyUcoAwlo6S585O5F42e-ESuh28eovy826zU1io17ywA40lXDwNwgbhF8a1GAyp8R90Vwlokwj86a5UO1nymUd81Zo6y0aFw9hwAwiUkFotO3o2iZw0zNg0BJDxS05M8&__req=4b&__beoa=1&__pc=EXP2%3Acomet_pkg&dpr=1&__ccg=EXCELLENT&__rev=1002161314&__s=1230in%3Abrvifg%3Amzu1bs&__hsi=6830485538918903931-0&__comet_req=1&fb_dtsg_ag=AQwgOCcgcTnzy1lHrbQZrrvOi7cJxlEv9ZUjz_UIpjST3Q%3AAQzhkyxOruEzbCZ3LoN8vL-SCR6BlPZlbK4ENaGWHzZyhw&jazoest=28405&__spin_r=1002161314&__spin_b=trunk&__spin_t=1590346344
Example json:
for (;;);{"bootloadable":{"BanzaiODS":{"r":["csr:_4b_2"],"rds":{"m":["BanzaiODS","BanzaiScuba"]}},"FbtLogging":{"r":["csr:_4b_3"]},"Banzai":{"r":["csr:_4b_4"],"rds":{"m":["BanzaiODS","BanzaiScuba"]}},"BanzaiScuba":{"r":["csr:_4b_5"],"rds":{"m":["BanzaiODS","BanzaiScuba"]}...
It's a protection againt JSON hijacking. The goal is to invalidate JSON data in order to prevent these kind of attacks.
You can find more information on JSON hijacking in the following links :
a presentation of JSON hijacking : https://dev.to/antogarand/why-facebooks-api-starts-with-a-for-loop-1eob
Is facebook suddenly safe against JSON hijacking?
Is JSON Hijacking still an issue in modern browsers?
I'm building a REST API in JAVA and C# and I was wondering about the way I should pass data to those services.
What I'm familiar with as the right way is to send JSON object as the data in the POST body:
{name:'Dor'}
but I can also pass a string and parse the JSON in my service:
'{name:'Dor'}'
What is the preferable way from performance factor? or any other factors?
Basically, if you need to send the json data across via jquery, then we need to use stringify, else the data would be serialized into to key=value pair.
So, you cannot send the json object directly via jquery ajax method.
How it works behind the hood:
In $.ajax function, if we provide data as
data :{key1:"value1", key2:"value2"}
is serialized to key1=value1&key2=value2
if we provide data as
data :'{key1:"value1", key2:"value2"}' or JSON.stringify({key1:"value1", key2:"value2"})
is sent as {key1:"value1", key2:"value2"}
So, what we can conclude is that, we cannot pass json object directly via jquery, we can send only json string. Hope this clarifies everyone.
I want to call a rest API and my request body is composed in a json file. I want to send the request as multipart/form. Request body containst some text fields and several files for which I decide to use multipart form. I have found alot of logical example requests on internet but no concrete example in json format.
How would a sample json request body look like?
Finally found out that there is no such JSON representation of multipart/data requests. Infect thats just not possible using the json format. So multipart data request literally looks like the attached screenshot:
I'm trying to execute example from here: https://developer.paypal.com/docs/classic/paypal-payments-pro/gs_PayPalPaymentsPro/
curl -s --insecure https://api-3t.sandbox.paypal.com/nvp -d "USER=platfo_1255077030_biz_api1.gmail.com&PWD=1255077037&SIGNATURE=Abg0gYcQyxQvnf2HDJkKtA-p6pqhA1k-KTYE0Gcy1diujFio4io5Vqjf&METHOD=DoDirectPayment&VERSION=78&PAYMENTACTION=SALE&AMT=5&ACCT=4660997962602322&CREDITCARDTYPE=VISA&CVV2=176&FIRSTNAME=James&LASTNAME=Smith&STREET=FirstStreet&CITY=SanJose&STATE=CA&ZIP=95131&COUNTRYCODE=US&EXPDATE=092015"
Documentation says:
Request method, format Response format
HTTP GET Name/value pairs JSON
But I receives:
TIMESTAMP=2015%2d01%2d30T12%3a14%3a08Z&CORRELATIONID=474de7dae8e82&ACK=Success&VERSION=78&BUILD=15009693&AMT=5%2e00&CURRENCYCODE=USD&AVSCODE=X&CVV2MATCH=M&TRANSACTIONID=93V64243P1844913T
Why? How to get json response?
I tried to set:
VERSION=95
but didn't help.
As document states the paypal NVP api doesn't straight away provide json response.
The way attained to process the response goes like below,
In PHP
parse_str($response,$responseArray);
$jsonResponse = json_encode($responseArray);
helped me to get the array from the response string and in turn converted to json.
Edit : you first need to decode the urlencoded string.
For that
$response = urldecode($response);
Before parsing the response to array.
While I do see the documentation you quoted (from https://developer.paypal.com/docs/classic/paypal-payments-pro/gs_PayPalPaymentsPro/), I think it's flat-out wrong.
I don't believe the classic PayPal APIs support JSON (except Adaptive Payments, which was written later # PayPal & is thus a bit more modern in some ways, including the JSON support).
See https://developer.paypal.com/docs/classic/api/gs_PayPalAPIs/, which describes the headers taht you can use to request JSON from the Adaptive APIs but clarifies that the other classic APIs don't support it.
New Relic currently URL encodes the JSON payload of our webhooks. We correctly include the necessary header, however, I'm wondering if this is best practice - or if the JSON payload should be sent un-encoded (or even with some different encoding)?
It's more common to send JSON directly in the request body with a Content-Type header value of application/json. It's not entirely uncommon to do it the way New Relic does however. GitHub post-receive hook payloads are also encoded this way.
In some languages/frameworks it's easier to extract the JSON data from a parameter than from reading the entire request body since form parameters are automatically parsed out and easily referenced and in some cases reading a request body may involve some more elaborate stream parsing.
An example of that is PHP's syntax for extracting the entire raw request body:
$data = file_get_contents('php://input');
var_dump(json_decode($data));
Versus extracting from a form parameter:
$data = $_POST["payload"];
var_dump(json_decode($data));
For frameworks that easily expose the request body, this isn't as much an issue. Here's the example given from the GitHub docs for handling the hook with Sinatra:
post '/' do
push = JSON.parse(params[:payload])
"I got some JSON: #{push.inspect}"
end
If the JSON body were passed directly, this is what it would look like:
post '/' do
push = JSON.parse(request.body.read)
"I got some JSON: #{push.inspect}"
end
It's mostly just an aesthetic preference, there's no technical advantage to either. With the parameter, you do get the flexibility of sending multiple JSON payloads in a single request or the option to send additional meta data outside the JSON. I would suggest sending a list of JSON objects and including all the meta data in a top level wrapper if that's important to you. Something like this:
{
"notification_id": "akjfd8",
"events": [ ... ]
}
I personally prefer raw JSON bodies, but that's mostly because it makes debugging far easier on sites like RequestBin. Your screenshot does a great job of illustrating how unreadable JSON encoded into a form parameter is.
<rant>
Payloads should be the content type you say they are. If they are sending as application/x-www-form-urlencoded then that is what you should expect to find. The culture of using a Russian doll model of nested encodings is beyond stupid in my opinion.
If you want to send JSON send it as application/json. Is that really so hard?
</rant>