OK. This is my first question on this illustrious site so forgive me if I've not researched etc.
I'm beginning to get my head round making API requests and I've also started to learn Python. I have a specific application that if I can work out how to do it, would make a huge difference to how I do things. I want to create a "middleman" to change the JSON structure of an API request.
I would have System A making a GET request to populate a data list. This system needs the response that looks like this…
"DataSources":[
{
"Id":"parties",
"Rows":[
[
"11587",
"null",
"null",
"Scott",
"Spacey",
"Creative Director"
And System B responds with something that looks something like this…
{
"parties": [
{
"id": 11587,
"about": null,
"title": null,
"firstName": "Scott",
"lastName": "Spacey",
"jobTitle": "Creative Director"
So, is there a practical way to create something that receives the GET requests from System A, converts it, and manipulates the response from System B in a new JSON structure that SYSTEM A can handle…
I've had the same issue. The below converts the API get request results from json to a python list of dictionaries. There might be a more elegant way, but this works for now. Hope this helps.
import requests, json
response = requests.get(strEndPointUrl)
## convert json to string and then string to Python list
strOutput = json.dumps(response.json())
ListOutPut = json.loads(strOutput)
for dictOutPut in ListOutPut:
print(['Key1'])
Related
I have a little Python program that other people use and I would like to offer opt-in telemetry such that can get an idea of the usage patterns. Google Analytics 4 with the Measurement Protocol seems to be the thing that I want to use. I have created a new property and a new data stream.
I have tried to validate the request and set it to www.google-analytics.com/debug/mp/collect?measurement_id=G-LQDLGRLGZS&api_secret=JXGZ_CyvTt29ucNi9y0DkA via post and send this JSON payload:
{
"app_instance_id": "MyAppId",
"client_id": "TestClient.xx",
"events": [
{
"name": "login",
"params": {}
}
]
}
The response that I get is this:
{
"validationMessages": [
{
"description": "Cannot parse non Measurement Protocol hits.",
"validationCode": "INTERNAL_ERROR"
}
]
}
I seem to be doing exactly what they do in the documentation or tutorials. I must be doing something wrong, but I don't know, what is missing. What do I have to do in order to successfully validate the request?
Try to remove /debug part in the URL. In the example you followed it is not present so it is not quite exactly the same.
we just came across the same issue and the solution for us was to put https:// in front of the URL. Hope this helps.
After not being able to get the provided python API to work (I simply do not know enough about authentication), but being able to use provided Postman collections to work,
I decided to try and replicate these Collection Endpoints in Python.
I got off to a good start with the auth endpoint
Here it is in Postman:
and my python code replicating this:
base_url = 'https://demo.docusign.net/restapi/v2/'
params = {'api_password':'true'}
headers = {'X-DocuSign-Authentication':json.dumps({"Username":username,"Password":password,"IntegratorKey": clientid}),
'Content-Type':'application/json'}
auth_req = requests.get(base_url+'login_information', params, headers=headers)
Auth request yields 200, just like Postman
But then I try another request to /templates/
Here it is in Postman:
and headers same as Auth request above
I tried many variations of the following:
params = {'accountId':'7787022'}
get_templates = requests.get(base_url+'templates', params, headers=headers)
No matter what I try, I get a 404 instead of a 200 like with postman.
Any idea what I'm doing wrong?
As per your comment, it looks like you don't have a fully built BaseUrl. The full body of a base URL will include the server, the rest API version and your account number. Aside from the Login Information and other authentication calls, all standard* REST API calls will start with https://{{server}}.docusign.net/restapi/v2/accounts/{{accountId}}/
A call to GET templates would be made to https://{{server}}.docusign.net/restapi/v2/accounts/{{accountId}}/templates.
*Organization API calls are coming soon and will likely use a different URL.
The following did not fix, but I thought it would fix, and still think it is importnat information:
In Postman auth call under 'Tests' there is the followign code
var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("accountId", jsonData.loginAccounts[0].accountId);
var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("baseUrl", jsonData.loginAccounts[0].baseUrl);
var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("password", jsonData.apiPassword);
even though this is 'Tests' it is useful for and often used to set variables, (some ppl at my old company used to do this).
In my python code, I need to take the response body from auth request:
{
"loginAccounts": [
{
"name": "Aiden McHugh",
"accountId": "7787022",
"baseUrl": "https://demo.docusign.net/restapi/v2/accounts/7787022",
"isDefault": "true",
"userName": "Aiden McHugh",
"userId": "e87........6a4eb",
"email": "aide....il.com",
"siteDescription": ""
}
],
"apiPassword": "HheDl......3MQ="
}
and use apiPassword variable to reset password in my header
You could also check out the python code example. It includes authentication and many examples.
Our team wants to automate our REST API testing. Right now, we have a collection of Postman requests and make them jump through hoops manually.
We could create a collection/folder for each testing scenario, but that would mean a ton of duplication. Our API is still under heavy development and I really don't want to fix the same thing at twenty places after it changes.
I would like to have each endpoint request only once in a collection and some kind of independent logic that can execute them in an arbitrary order. I know Postman doesn't support request reuse in any clean way, so I am looking for at least a hacky way how to do it.
Create a file to load into the Postman Collection Runner, with the following structure:
[{
"testSequence": ["First request name", "Second request name", "..." ],
"anyOtherData": "Whatever the request needs",
"evenMoreData": "Whatever the request needs",
"...": "..."
},{
"testSequence": ["Login", "Check newsfeed", "Send a picture", "Logout" ],
"username": "Example",
"password": "correcthorsebatterystaple",
},{
"...": "keep the structure for any other test scenario or request sequence"
}]
Put all your test sequences in that file, then make Postman check the list after each request and decide what to execute next. This can be done e. g. in a "tests block" of the whole collection:
// Use the mechanism only if there is a test scenario file
// This IF prevents the block from firing when running single requests in Postman
if (pm.iterationData.get("testSequence")) {
// Is there another request in the scenario?
var sequence = pm.globals.get("testSequence");
if ((sequence instanceof Array) && (sequence.length > 0)) {
// If so, set it as the next one
var nextRequest = sequence.shift();
pm.globals.set("testSequence", sequence);
postman.setNextRequest(nextRequest);
} else {
// Otherwise, this was the last one. Finish the execution.
postman.setNextRequest(null);
}
}
If your requests need to use different data during different runs, you can define the data in the input file and use them as variables in the request.
Referencing this API tutorial/explanation:
https://thinkster.io/tutorials/design-a-robust-json-api/getting-and-setting-user-data
The tutorial explains that to 'follow a user', you would use:
POST /api/profiles/:username/follow.
In order to 'unfollow a user', you would use:
DELETE /api/profiles/:username/follow.
The user Profile initially possesses the field "following": false.
I don't understand why the "following" field is being created/deleted (POST/DELETE) instead of updated from true to false. I feel as though I'm not grasping what's actually going on - are we not simply toggling the value of "following" between true and false?
Thanks!
I think that the database layer have to be implemented in a slightly more complex way than just having a boolean column for "following".
Given that you have three users, what would it mean that one of the users has "following": true? Is that user following something? That alone cannot mean that the user is following all other users, right?
The database layer probably consists of (at least) two different concepts: users and followings; users contain information about the user, and followings specify what users follow one another.
Say that we have two users:
[
{"username": "jake"},
{"username": "jane"}
]
And we want to say that Jane is following Jake, but not the other way around.
Then we need something to represent that concept. Let's call that a following:
{"follower": "jane", "followee": "jake"}
When the API talks about creating or deleting followings, this is probably what they imagine is getting created. That is why they use POST/DELETE instead of just PUT. They don't modify the user object, they create other objects that represent followings.
The reason they have a "following": true/false part in their JSON API response is because when you ask for information about a specific user, as one of the other users, you want to know if you as a user follows that specific user.
So, given the example above, when jane would ask for information about jake, at GET /api/profiles/jake, she would receive something like this:
{
"profile": {
"username": "jake",
"bio": "...",
"image": "...",
"following": true
}
}
However, when jake would ask for the profile information about jane, he would instead get this response:
{
"profile": {
"username": "jane",
"bio": "...",
"image": "...",
"following": false
}
}
So, the info they list as the API response is not what is actually stored in the database about this specific user, it also contains some information that is calculated based on who asked the question.
Using a microPUT would certainly be a reasonable alternative. I don't think anybody is going to be able to tell you why a random API tutorial made certain design decisions. It may be that they just needed a contrived example to use POST/DELETE.
Unless the author sees this question, I expect it's unanswerable. It's conceivable that they want to store meta information, such as the timestamp of the follow state change, but that would be unaffected by POST/DELETE vs. PUT.
I'm using Meteor to consume a remote API. One of the endpoints of this API requires an (ordered) array of credentials, so the data would look like
{
"country": "de",
"credentials": ["admin", "password"],
"whatever": "whatever"
}
When I provide this plain-object as the value to param property of HTTP.post like this
HTTP.post('https://api.whatever.org/whatever', {
headers: {
"Authorization": "Basic ".concat(...)
},
params: {
"country": "de",
"credentials": ["admin", "password"],
"whatever": "whatever"
}
});
then the parameters are packed this way:
country=de
credentials=admin,password
whatever=whatever
but they should be packed this way:
country=de
credentials=admin
credentials=password
whatever=whatever
I tried using a Content-Type header but it didn't help.
I tried using content and data instead of params with different outcomes and then ended concatenating all the values into a query string an putting it into content property. But this isn't really a nice piece of code and surely not one that is easy to maintain.
I've read docs but haven't found anything that would help.
Where should I look for the information regarding this topic? Is there a better way to override the way HTTP.post (or, in general, HTTP.call) computes the body of the query to send?
Where should I look for the information regarding this topic?
In the source code.
I know nothing about Meteor, but I’m looking into its source code and I see no public hook which could help you. Of course, you can replace URL._encodeParams with your own function, but that is less maintainable than submitting the encoded params as raw data.