Postman chrome extension with array of hashes as value - google-chrome-app

I have a data that looks like this:
I took a look at this post Array value on postman chrome extension, so I know how to use postman to send post request with parameters from age to skillset, my problem is the work_experience, it's an array of hashes, I want to input the work_experience in postman, from which you can see is an array of hashes.
So is this possible? And if you know a better chrome extension that can do this, feel free to answer or comment
P.S.
Although this is should be obvious, but for the sake of the person who voted to close this for being unclear, my purpose is to simulate what my mobile ios app would send to my server's api without actually using the ios app to type on every textfield every time I run the app.

You can put nested sub-keys in brackets. So you could define some of your key/value pairs in the form-data fields like this:
key: work_experience[0][company_name]
value: asdfdfaf
key: work_experience[0][end_date]
value: 12/21/2121
key: work_experience[1][company_name]
value: fdjfkjdfjk
key: work_experience[1][end_date]
value: 1/3/15

You can try you sending it as a "raw" data" (and not a form-data or form-urlencoded)

U can also try as below... its worked for me
key: work_experience[0].company_name
value: asdfdfaf
key: work_experience[0].end_date
value: 12/21/2121
key: work_experience[1].company_name
value: fdjfkjdfjk
key: work_experience[1][end_date]
value: 1/3/15

You can send the data by choosing the raw option in Body and Content-Type as application/json in headers in postman's POST request option. This is how you can form the data while sending it -
{ "work_experience": [{"company_name": "asd", "end_date": "12/12/2121",
"leave_reason": "asdasdasd", "position": "asdasd",
"start_date": "12/12/2012"}]
}

Related

Is anyone knows how Flutter URI encoding/decoding works?

Is anyone knows how Flutter URI encoding/decoding works?
I have one issue. Let me give you some background on the issue. We have one deep link which will give us the email and access token code to reset the password. We will validate the token on the front end and then allow users to do a reset.
Here is the sample URL from Firebase dynamic link
https://example.com/auth/resetPassword/?access_token=abcd&email=test+abc#xyz.com
Firebase dynamic link will give us this URL in the URI object. The issue is when I try to fetch the query params from this URI object, it removes plus sign from an email and replaces it with the space character instead. E-mail should same as displayed in the above link. This is the email received when I fetch query params: test abc#xyz.com
I have created two dart pads to figure out the issue. Here is the 1st sample where I am parsing (since firebase dynamic link is doing the same) the URL into the URI object and tried printing the output. As expected it removes the plus sign.
Code:
main() {
var httpsUri = Uri.parse("https://example.com/auth/resetPassword/?access_token=abcd&email=test+abc#xyz.com");
print(httpsUri.queryParameters);
}
Output:
{access_token: abcd, email: test abc#xyz.com}
In another sample, I tried creating the URI object from the same parameters and link but manually. Here is the code
Code:
main() {
var httpsUri = Uri(
scheme: 'https',
host: 'example.com',
path: '/auth/resetPassword/',
queryParameters: {
'access_token': 'abcd',
'email': 'test+abc#xyz.com'
});
print(httpsUri.queryParameters);
}
Output:
{access_token: abcd, email: test+abc#xyz.com}
If you see here, the email is correctly displayed.
My exact scenario is matching with the first sample code. Based on my findings it removes the plus sign due to encoding and decoding of the URL as a plus sign has a special meaning in the URL. But on the other hand why it is not happening in 2nd example?
Any help would be appreciated!
+ is a reserved character for URIs and therefore should be encoded to %2B if you want a literal + character.
But on the other hand why it is not happening in 2nd example?
Your second example works because it constructs a Uri object directly, and if you were to convert it to a String, it would perform necessary encodings for you. That is, print(httpsUri) would output:
https://example.com/auth/resetPassword/?access_token=abcd&email=test%2Babc%40xyz.com
rather than original (malformed) URL:
https://example.com/auth/resetPassword/?access_token=abcd&email=test+abc#xyz.com

Linkedin Ads API What's the format of the `dateRange` request parameter?

What's the right format for dateRange for rest-li v2?
The current examples in the documentation do not support it, and I don't understand from the rest-li documentation what's the format for it, exactly.
This is the request I make:
Headers:
X-Restli-Protocol-Version: 2.0.0
Authorization: Bearer <token-here>
URL (with request parameters):
https://api.linkedin.com/v2/adAnalyticsV2?q=analytics&pivot=CAMPAIGN&dateRange.start.day=1&dateRange.start.month=1&dateRange.start.year=2017&timeGranularity=DAILY
OR
URL - deconstructed (with request parameters):
Base URL:https://api.linkedin.com/v2
Params:
q:analytics
pivot:CAMPAIGN
dateRange.start.day:1
dateRange.start.month:1
dateRange.start.year:2017
timeGranularity:DAILY
Error I get:
{
"serviceErrorCode": 100,
"message": "Unpermitted fields present in PARAMETER: Data Processing >Exception while processing fields [/dateRange.start.day, /dateRange.start.month, >/dateRange.start.year]",
"status": 403
}
Note: I'm referred to a question with the same error in the comments, however this might be caused by a different reason, and the answer there does not work for me. If by StackOverflow's standards you still think that it's a duplicate, please let me know and I'll close this question.
The first solution didn't work for me. As Linkedin's API documentation is shit in regards to this it took me a lot of trial and error. #Gal-Grünfeld final structure is correct but the example isn't. Linkedin's docs say the key is dateRange.start which is wrong.
dateRange=(start:(day:1,month:9,year:2020))
Solution provided by one of the LinkedIn developers:
For Restli version 2, for parameter dateRange (tested only for endpoint AnalyticsV2):
rangeDate := (start[,end]) (end is optional)
start, end - type: Date
Date := (day, month, year)
day - type: integer (tested for single digit only)
month - type: integer (tested for single digit only)
year - type: integer (tested for 4 digits only)
Final structure (not including the optional end):
dateRange=(start:(day:,month:,year:))
Example:
dateRange=(start:1,month:1,year:2017)
When you are using Python and requests, the working format of 'dateRange' parameter is:
params = {
'q': 'analytics',
'dateRange.start.day': '1',
'dateRange.start.month': '1',
'dateRange.start.year': '2022',
'pivot': 'COMPANY',
'timeGranularity': 'DAILY'
}
But remember to remove (or not use at all) the header "X-Restli-Protocol-Version"
Be careful about the query parameter encoding, I am using Faraday library for HTTP get requests and it encodes the query string, so I am correctly using the dateRange=(start:(day:1,month:9,year:2020)), but at the end Faraday encodes it to something like this: dateRange%3D%28start%3A%28day%3A1%2Cmonth%3A9%2Cyear%3A2020%29%29. But linkedin expects the first brackets unencoded, I had same problem with other endpoint, where the List(something) was not working, but with curl it was working, the difference is encoding.

REST: Is it considered restful if API sends back two type of response?

We have stock website and we help buyers connect with the sellers. We are creating API to let buyers push their contact details and get back the seller details. This is transaction and get logged in our database. We have created following API:
The request is POST, the URL looks like:
/api/leads
The request body looks like:
{
"buyermobile": "9999999999",
"stockid": "123"
}
The response looks like:
{
"sellermobile" : "8888888888",
"selleraddress": "123 avenue park"
}
We have a new requirement, i.e. we need to send back PDF URL (instead of "sellermobile" & "selleraddress"). This PDF URL would contain the seller details in case it comes from one of our client.
We have modified the same API, now the request body looks like:
{
"buyermobile": "9999999999",
"stockid": "123",
"ispdf": true
}
The response looks like:
{
"sellerdetailspdf" : "https://example.com/sellerdetails-1.pdf",
}
Is it RESTFUL to do this? OR we should create separate API for getting response as PDF?
I wouldn't approach it this way. What happens when you need to add XLS? Do you add "isxls" to the request too?
Things I'd consider:
Use a mime type for content negotiation. Post the same request, and specify in the Accept header what you expect back - JSON, PDF, etc. You're then actually getting the report instead of a link to the report, which may or may not be better.
- or -
Include a link in the typical lead response.
{
"sellermobile" : "8888888888",
"selleraddress": "123 avenue park",
"_links": {
"seller-details-pdf": "https://example.com/sellerdetails-1.pdf"
}
}
- or -
Support a query parameter that specifies the type in the response.
- or -
Have a single property that specifies the type in the response, rather than a boolean. Much cleaner to extend when you add new response types.
The first two options have the bonus that you don't require clients to handle multiple response types to a single request. That's not forbidden by any spec, but it's annoying for clients. Try not to annoy the people who you want to pay you. :)
Again the implementation looks good to me, however you could potentially look at breaking the return of the PDF URL to another endpoint maybe something like api/lead/pdf that way your request body is the same for api/lead and all subsequent endpoints under /lead. Allowing your routes and other code to handle small portioned tasks instead of having a route that handles multiple flags and multiple code routes.
That looks good to me - the same type of input should give the same type of response but in your case you have two different types of input - one with the "ispdf" flag and one without. So it's consistent to responds with two different types of response, one with the PDF link and one without.
That's still something you'll want to document but basically it's a correct implementation.

How we can handle dynamic web service in iPhone?

I am learning some tricky development in iPhone and during my experiments I found out that usually we used localized web-service in which all parameter are fixed(Keyword). If my web service will change some fields in the response than how can we handle in iPhone. Please help me. If Anybody have any good idea.
For Example,
Webservice Response1:
[    {
      "Number":"A12 hrb",
      "List":[
         {
            "Type":"Works",
            "Display":{
               "dop":45,
               "dopper":56
            },
            "OAST":"10-01-2012",
            "OAET":"07-04-2012",
            "Cause":"define",
            "Impact":"Queue",
            "Description":"Take a Break.",
            "LName":"Lunetten To Lunetten",
            "Number":"A12 hrb",
         }
      ]    },   ]
Webservice Response2:
[    {
      "Number":"A12 hrb",
"Number2":"A13 brs",
      "List":[
         {
            "Type":"Works",
            "Display":{
               "dop":45,
               "dopper":56
"picker":90
            },
            "OAST":"10-01-2012",
"MAET":"07-04-2012",
            "OAET":"07-04-2012",
            "Cause":"define",
            "Impact":"Queue",
            "Description":"Take a Break.",
            "LName":"Lunetten To Lunetten",
            "Number":"A12 hrb",
         }
      ]    },   ]
You can do this
Parse the response.If response is JSON then definitely you will get a dictionary just keep a reference of it.
you can get all the keys in dictionary by calling following method
(NSArray *)allKeys
now enumerate above array and access the values respective to each key and do whatever you want
But you should know the meaning/purpose of dynamic keys. If you don't no meaning/purpose of keys these steps may not help you... best of luck.
For this type of case you can get the dictionary and in dictionary you
can get the value of which tag you want means you just need root node
and store root node all the data in dictionary and handle that
dictionary for the further use..
I don't think it will be possible to parse it completely. Atleast you should know which keys are going to be there. e.g. response has Number, Number2 & List as keys. It's ok if some responses do not contain one/some of the keys.
On the other hand, if knowing all the keys in advance is at all not possible, then webservice should have mechanism to convey the keys used in response.
e.g. [ {
"dynamic_keys": "Number2",
"Number":"A12 hrb",
"Number2":"A13 brs",
"List":[
{
"Type":"Works",
"Display":{
"dop":45,
"dopper":56
"picker":90
},
"OAST":"10-01-2012",
"MAET":"07-04-2012",
"OAET":"07-04-2012",
"Cause":"define",
"Impact":"Queue",
"Description":"Take a Break.",
"LName":"Lunetten To Lunetten",
"Number":"A12 hrb",
}
] }, ]
You can read the value of "dynamic_keys" and then using that value you can read value of actual dynamic key.
edit: as mentioned by ssteinberg you can use some framework like JSONKit to parse actual JSON.
See this as well: How to parse JSON having dynamic key node

facebook, how to send tracking info for the user inside data?

i am using this example to send messages to my friends.
the problem i get into is how do i use the data property to add some tracking info.
I would like to pass a var $test and then be able to read it in a json format, or even an array.
In other words, I would like to pass a var when i send the message and when they accept it and it redirect them to the canvas, i would like to be able to grab it from somewhere:
ex:
"data":[
{
"id":"167548189960088",
"application":{
"name":"Cat's Test Site",
"id":"314268391344"
},
"to":{
"name":"Cissy Lim",
"id":"100001147247007"
},
"data":"'here is my var'",
"message":"'INSERT_UT8_STRING_MSG'",
"created_time":"2011-02-16T08:37:02+0000"
},
Thanks
The "data" parameter currently only supports a string. Very annoying since Facebook seems to support json objects everywhere else. You could put a "json string" there and then eval that to a json object when you want to read it.