I make a post request with a different json file every hour and I wondered if I can make this automated? I searched online and it looks like it can be done with collection runner or monitors?
URL: https://api.keepa.com/tracking?key=MY_API_KEY&type=add
Headers: Content-Type application/json
Body:
{"asin":"value",
"ttl": value,
"expireNotify": value,
"desiredPricesInMainCurrency": value,
"mainDomainId": value,
"updateInterval": value,
"metaData": value,
"thresholdValues":{"thresholdValue": value,"domain": value,"csvType": value,"isDrop": value},
"notifyIf": value,
"notificationType": value,
"individualNotificationInterval": value},
One json file has 1000 of these object. I have 100 json files.
Can someone give me some information about this please? Can I automate it with collection runner?
There are too many ways to schedule your Postman requests and one is creating a Postman monitor. Check this article to learn how to start. If you want to specialize your request you can use the Pre-request Script and Tests section.
Sample Pre-request:
Sample Test:
Monitor Console Log:
PS: There is a quota for free Postman accounts. Total 1000 requests per month for Postman Monitoring. Buy a premium account or learn how to use Newman (Postman CLI) and how cron jobs work for making the same thing for free.
Related
I already figured out the URL is https://spclient.wg.spotify.com/color-lyrics/v2/track/${TRACK_ID}?format=json&vocalRemoval=false
And it requires two headers. app-platform: WebPlayer and authorization: Bearer TOKEN.
So using curl I am able to get the lyrics information like that:
$ TRACK_ID=3z8h0TU7ReDPLIbEnYhWZb
$ BEARER_TOKEN=xxxxxxxxxxxxxx
$ curl "https://spclient.wg.spotify.com/color-lyrics/v2/track/${TRACK_ID}?format=json&vocalRemoval=false" -H "app-platform: WebPlayer" -H "authorization: Bearer ${BEARER_TOKEN}"
{
"lyrics": {
"syncType": "LINE_SYNCED",
"lines": [
{
"startTimeMs": "110",
"words": "Is this the real life? Is this just fantasy?",
"syllables": [],
"endTimeMs": "0"
},
{
"startTimeMs": "6990",
"words": "Caught in a landslide, no escape from reality",
"syllables": [],
"endTimeMs": "0"
},
...
The actual question is how do I programmatically get the required bearer token? I've tried a token requested using Get Token button on this site: https://developer.spotify.com/console/get-track/
But that token only appears to work for the official API. For the lyrics API I always get the following response for that token:
{
"error": {
"status": 403,
"message": "Client not allowed"
}
}
Also, the bearer tokens from the link above are way shorter and contain no dashes.
I know I can just copy the Bearer Token that is used by the web client on https://open.spotify.com but the token always expires after a very short amount of time.
So I'm either looking for a manual way to get a permanent token or for a way to programmatically get short-lived tokens.
I'm not looking for a solution in a specific programming language. Any language will do or an abstract explanation.
This API is not designed nor documented for public use, and is additionally not licensed (see Musixmatch's API, where Spotify gets their lyrics from anyway), so using it (or bragging about finding it on StackOverflow) will likely only have Spotify further lockdown their API, and you (unlikely but possibly) getting into legal trouble (IANAL).
That being said, these Bearer xxx tokens are different to the ones created from Spotify's official API, and the easiest way to find these tokens is just by automating the process of logging in (probably in a browser), and making the request (these tokens may need to be refreshed either every few minutes/hours/days, so automation is key here). I'd suggest to start looking into Puppeteer or MS Playwright on a headless browser, and just retrieving Bearer tokens from there. If the API seems to break with those Bearer tokens, it may be best to perform the request from Puppeteer itself in the browser, by replicating the original request, and amending the song ID.
I am aware btw of how annoying Musixmatch can be, so I completely understand if the 2nd paragraph is the way you're going to go.
You can use the token from here: https://open.spotify.com/get_access_token
The only downside is, that it's not documented, but so is spclient.wg.spotify.com
every now and then I come to this question, google around for some time without getting a definitive answer and let it be.
Problem:
I want to update an existing resource, but the logic how this update works is on the backend side.
Let's assume a product should only be visible for a set time. Keeping it simple. The time "from" is stored in the database along the product data: product.visibleFromDate and the duration (eg. 30 days) is just a variable or configured somewhere (not in DB).
Now I want to call the backend telling it to update the visibleFromDate to "now": /api/product/:id/updatevisibility
In this case I don't want to send a body because the server should determine what value "now" really is.
I actually don't really care if the server answers with the updated resource or no content.
HTTP Request
GET
Should not be used because it should be idempotent, which it wouldn't be because the visibleFromDate would be updated
POST
Don't want to send the date from frontend
PUT
Don't want to send the date from frontend + should be idempotent
PATCH
Merge Patch: Don't want to send the date from frontend
JSON Patch: Again, I don't want to send a value, I want the backend to determine it.
Of course I could just send an empty object, the whole resource or some nonsense and ignore it on the backend side, but still I feel like I am missing this "trigger" type of requests which only need the type of resource, id and action.
Depending on the mutability of the data it should either be POST(immutable) or PATCH(mutable). It doesn't depend on what You're sending or not sending.
If You really want to do it by the book then you should send a '{}' when there are no fields to send. If any is added later you will just add it like '{"duration":"30"}'
You would definitely want POST over GET for authorization/authentication purposes.
You don't need to have a body for a POST request. Your endpoint will just listen for a request, it will extract :id, and then run your time update function.
PUT and PATCH are semantic equivalents to POST. Unless you programmed the backend to differentiate them, there won't be any difference. You don't even need them at all.
A single empty-body POST will be enough for your endpoint. But you may consider using empty-body PATCH just as a meaningful endpoint. In both cases, your backend will extract the :id and then just run the same function (after auth* if any)
EDIT: Seems not all people can grasp what I have, so here are a working nodejs/express backend and curl requests to use. you don't need a request body, and all behave the same, except semantics and security over GET.
this is the server code:
const express = require('express');
const app = express();
const port = 3000
const updatetime = async (id)=>{
let newdate=Date.now();
console.log(`updating resource ${id} to have a new date ${newdate}`);
return Promise.resolve("done")
}
const processrequest=async (req, res) => {
console.log(req.method);
console.log(req.headers);
console.log(req.headers.authorization);
console.log(req.body)
console.log(req.params)
try{
let result=await updatetime(req.params.id);
console.log(result);
res.status(200).send("time updated")
}catch{
res.status(500).send("something went wrong")
}
}
app.get( '/:id/updatetime', (req, res) => processrequest(req,res))
app.post( '/:id/updatetime', (req, res) => processrequest(req,res))
app.put( '/:id/updatetime', (req, res) => processrequest(req,res))
app.patch('/:id/updatetime', (req, res) => processrequest(req,res))
app.listen(port, () => {
console.log(`listening on port ${port}`)
})
test all endpoint without a body, all works because magic:
curl -X GET -H "Authorization: Basic" localhost:3000/123qwe/updatetime
time updated
curl -X POST -H "Authorization: Basic" localhost:3000/123qwe/updatetime
time updated
curl -X PUT -H "Authorization: Basic" localhost:3000/123qwe/updatetime
time updated
curl -X PATCH -H "Authorization: Basic" localhost:3000/123qwe/updatetime
time updated
server output for all request types are the same because it is just a magic(!) that is developers' choice of implementation:
listening on port 3000
GET/POST/PUt/PATCH
{
host: 'localhost:3000',
'user-agent': 'curl/7.78.0',
accept: '*/*',
authorization: 'Basic'
}
Basic
undefined
{ id: '123qwe' }
updating resource 123qwe to have a new date 1656495470330
done
You are not required to pass a body in a request (Although the specification says so), PATCH will be your best option here since semantically it is updating an “part of existing resource” while PUT is meant for "updating the entire resource".
my other answer did not satisfy you, so i will try the same but from a different viewpoint.
you are data engineer:
you don't retrieve any data with this operation, so no GET.
you operate on already-existing data, so no POST.
you don't change the whole data, so no PUT.
you are partially changing the data, see, you just use PATCH for the operation.
you will send an empty body {} to be consistent
you are an operational backend engineer.
GET is still considered to be used to retrieve a resource.
you want to run a function on the server which will partially modify the resource having the id given as the parameter in the url, so just use a POST request. it is like calling a function in your programming language.
or try PATCH to get the sympathy of your users.
or use PUT to get their anger when they realized what happens.
it is already getting the id from the URL, so you don't have to send any body unless your frontend API forces. curl won't send a body if you don't give one, for example.
semantics are not hard-coded rules. they are there to guide you and keep you in the line as much as possible. the problem is that they don't have solid implementation details. they are also "opinions" of a group of people which has pretty fine shape anyone can accept.
PS: It is said, "POST can be used on an already-existing data to append". sure it is, but the question in scope asks about changing a field, not creating a new one.
I have to write sign on peoplecode to make a service call by passing token (sent from third party) to API and get the responce (if token is valid responce will have username) in json format to create a PS_TOKEN.
I am fresher to peoplecode. How can I run HTTP POST request by passing token and get the response using Peoplecode?
You would create a synchronous service operation in the Integration Broker. The Integration Broker works best if you are sending XML or JSON. If this is just a regular HTTP POST with fields then it can cause some issues with the Integration Broker. I had a similar case and could not get the basic HTTP Post to work but instead ended up using HTTP POST multipart/form-data and was able to get that to work.
Steps I had to do to make this work.
Create a Message (document based or rowset based are both possible)
Create Service Operation and related objects
Create Transform App Engine to convert the Message to a HTTP POST multipart/form-data
Create a routing and modify the connector properties to send the content type of multipart/form-data. Also call the Transform app engine as part of the routing.
The issue with a application/x-www-form-urlencoded POST is that it seems PeopleSoft does another url encoding after the Transform, which is the last time you can touch the output with code. This final url encoding was encoding the = sign in the form post which made the format invalid.
Your other option would be to write this is Java and call the Java class from within PeopleSoft (or mix the Java objects in with PeopleCode). If you choose to go this way then the App Server needs to have connectivity to your authentication server. My only experience with this is I had a client that used this approach and had issues under heavy load. It was never determined the cause of the performance issue, they switched to LDAP instead to resolve the issue.
I followed the Quick Start Guide on Marketo's site for their REST API. This went well. I was able to get a successful response from their website.
Request:
curl https://ABC-DEF-123.mktorest.com/rest/v1/lists.json?access_token=123:ab
Response:
{"requestId":"123#abcf7aff","result":[],"success":true}
However, when I tried the same request the next day, I received:
{"requestId":"123#abc6731ab6f","success":false,"errors":[{"code":"601","message":"Access token invalid"}]}
I logged into the Marketo admin and noticed that the token I copied and pasted out of the dialog box was different. I tried this new one and it worked.
(This is taken from the guide)
I came across another guide on their site that describes a different authentication process. Marketo Authentication Guide
This guide mentions the token that is returned from the API endpoint has an expiration so I suspect that all Marketo tokens expire (or I need to disable this). However, I have not been able to successfully make requests to this endpoint with my client ID and client secret.
Request:
curl https://ABC-DEF-123.mktorest.com/identity/oauth/token?grant_type=client_credentials&client_id=ACLIENTID&client_secret=ACLIENTSECRET
Response:
{"error":"unauthorized","error_description":"An Authentication object was not found in the SecurityContext"}
Any help in the right direction would be appreciated. Thanks in advance.
REST API tokens expire. So you typically will need to request a token for each session.
from your specific installed URL, like: MARKETOURL/identity/oauth/tokengrant_type=client_credentials&client_id=abc&client_secret=xyz
Which will result in (example):
{
"access_token": "1234",
"token_type": "bearer",
"expires_in": 3599,
"scope": "email#email.com"
}
You will need to start out your sessions with this request to do subsequent calls. I have code that runs this first and then requests a new token if it expires. The expires_in field is in seconds.
Source: http://developers.marketo.com/documentation/rest/authentication/
I was not able to figure out why my curl requests were failing, but I was able to successfully call the Marketo API with mrkt, a Ruby Gem for Marketo.
I've looked through the logs of what the gem is generating for requests and they appear to be exactly the same. But at least I now successfully calling Marketo.
You need to use following sequences.
grant_type= client_credentials
client_id =you will get Marketo admin where you generate token
client_secret=you will get Marketo admin where you generate token
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
GET <Identity URL>/oauth/token?grant_type=client_credentials&client_id=<Client Id>&client_secret=<Client Secret>
Your first call failed because your token expires every hour currently, according to Marketo's docs.
Your curl call to get a new token failed because curl (or something) was stripping off the auth arguments. Try wrapping the url in quotes.
curl "https://ABC-DEF-123.mktorest.com/identity/oauth/token?grant_type=client_credentials&client_id=ACLIENTID&client_secret=ACLIENTSECRET"
You can get more information about what curl is sending with the -v flag. Running this would have given you enough information to at least know that your entire url wasn't being passed down to the request.
curl -v https://ABC-DEF-123.mktorest.com/identity/oauth/token?grant_type=client_credentials&client_id=ACLIENTID&client_secret=ACLIENTSECRET
I have a web-servise which listens to the JSON requests from different data sources. I want to identify data source by special parameter data-source. My question is how I can add field "data-source": "jira" to the webhook JSON body?
EDIT
For now my solution is to add to my webhook uri http://127.0.0.1:8080/DC data source parameter like this: http://127.0.0.1:8080/DC?data-source=jira, then check data source type and if it is equal to jira send request JSON body to method jiraJsonParser().
But I'm not sure if it is the best solution, isn't it?
I had a similar need, and solved the problem by creating a REST API with flask that acts as an aggregator/translator to accept requests from multiple tools, format the request as needed, and pass it on to it's intended target. For example, I have a Jira 'build request' ticket that sends a POST request via webhook to my API upon ticket creation. The API accepts the request, formats it as needed, fwd's the request on to Jenkins to run a build. As each part of the build runs, Jenkins sends requests back to the API, which get formatted as needed, and the original Jira ticket gets updated with the details/status of the build.
Here's a good article on building a REST API with flask - http://blog.luisrei.com/articles/flaskrest.html