I want to write a postman test that verifies if required fields in the body exists once I send the request, and if they do not exist then fail the test. I'm struggling to find how to write such a test, in my case I need "department.name" and "jobFunction" to be required.
Request body:
{
"id": 123,
"department": {
"id": 1,
"name": "Sales"
},
"jobFunction": [
"Manager",
"VP"
]
}
Would love and appreciate some help :) Thanks!
Related
I'm using Facebooks Webhooks for lead generations. I successfully can fetch leadgen_id from the Facebooks callback.
So this is what Facebook returns for the leadgen field:
{
"object": "page",
"entry": [
{
"id": "0",
"time": 1583178814,
"changes": [
{
"field": "leadgen",
"value": {
"ad_id": "444444444",
"form_id": "444444444444",
"leadgen_id": "444444444444",
"created_time": 1583178812,
"page_id": "444444444444",
"adgroup_id": "44444444444"
}
}
]
}
]
}
Is it possible to somehow get campaign ID from these values?
I figure out how to get the campaign id from leadgenId. we can use the Facebook graph leadgen GET API
GET /v6.0/<leadgenid>?access_token=<ACCESS_TOKEN>&fields=campaign_id'
Host: graph.facebook.com
Hope it'll help someone in the future :)
This is my response.
[
{
"id": 123,
"name": "text1"
},
{
"id": 456,
"name": "text2"
},
{
"id": 789,
"name": "text3"
}
]
I can just provide the name value and want to get back the id attribute. I am using rest assured. I can create a map and then get it accordingly but searching for solutions like jsonPath().get(id where name ="text2"). Just thinking if anything can be done like that.
You can use conditions like .find{it.name=='text2'}.id
I am getting the following back as a webhook (Message-Delivered Callback) but I need to get the actual content of the message that was delivered. The Message-Received Callback has a "text" field that contains this information, but this one does not.
{
"object": "page",
"entry": [{
"id": 2880130XXXX7538,
"time": 1462299418787,
"messaging": [{
"sender": {
"id": 1261XXXX3865793
},
"recipient": {
"id": 2880XXXX7977538
},
"delivery": {
"mids": ["mid.146XXXX412750:6bd62757XXXXd68848"],
"watermark": 1462XXXX12769,
"seq": 50
}
}]
}]
}
I have tried unsuccessfully to use graph api with the message id but the docs are a little unclear if this is possible (https://developers.facebook.com/docs/graph-api/reference/v2.6/message/)
The token I am using has the following permissions: read_page_mailboxes, manage_pages, pages_messaging.
Any help would be greatly appreciated!!
Add "m_" to your delivery mids, so in this case:
m_mid.146XXXX412750:6bd62757XXXXd68848
And then make a facebook-graph-api request using that as the "message-id" in the URL. Use fields=message to get the message text.
Reference:
https://developers.facebook.com/docs/graph-api/reference/v2.6/message/
You can try this code:
$M = $input['entry'][0]['messaging'][0]['message']['text'];
AND "$M" is what you want.
it's work! But i can't explain why
With Ember Data and Jsonapi. How is a json paginated resource supposed to look like?
I built my response so it looks like:
"meta": {
"page": {
"number": 1,
"size": 5,
"total": 39
}
},
"links": {
"self": "http://localhost:3099/api/v1/articles",
"prev": null,
"next": "http://localhost:3099/api/v1/articles?page[number]=2",
"first": "http://localhost:3099/api/v1/articles?page[number]=1",
"last": "http://localhost:3099/api/v1/articles?page[number]=39"
},
"data": [
...
]
But I am not exactly sure if this is the right format. based on the explanation at http://jsonapi.org/format/#fetching-pagination
Or, are the pagination links (i.e. prev, next, first and last) supposed to be in meta.page ?
You could use ember-cli-pagination and its format to do pagination. I'm pretty sure Ember Data does not follow the JSON API spec strictly.
Based on your sample this could be a format:
{
"meta": {
"total_pages": 3,
"page": 1
},
"articles": [
{"id": 1, "title": "Hello World", "body": "More to Come"},
// ......
]
}
The request URL of this payload could be http://localhost:3099/api/v1/articles?page=1. See the API for more info.
Ember Data doesn't follow the JSON spec strictly so you should concentrate more on setting up the JSON with what ED needs. I would personally move the 'links' info into the meta tag. Otherwise Ember-Data will attempt to put them into a model called 'links', which may not be what you want. If you do intend to store those inside a separate 'links' model, then what you have is fine.
I'm working on a web service API using the HATEOAS REST representation.
My client can create an item (e.g. a stub of a blogpost):
POST /item
204 Created
Content-Type: application/vnd.foo.item+json
{
"id": 42,
"title": "Lorem Ipsum",
"status": "STUB",
"body": "Very long text."
"_links": {
"self": {
"href": "/item/42"
},
"activate": {
"href": "/item/42/activate"
},
}
}
After that the client can activate the item following the activate link (e.g. go live with the post). So it makes another call to the API:
POST /item/42/activate
200 Ok
Content-Type: application/vnd.foo.item+json
{
"id": 42,
"title": "Lorem Ipsum",
"status": "ACTIVE",
"body": "Very long text."
"_links": {
"self": {
"href": "/item/42"
},
"permalink": {
"href": "/item/42/permalink"
}
}
}
Up to here it is fine. But the problem is that I'm looking for a way to tell the client a suggestion about the next action to do (it's backend business logic).
In my case could be:
Bring the user to post page following the permalink
Bring the user to a shop cart to buy post extra features (visibility, more images, homepage positions and so on...)
Tell the user that the post is pending content review
I don't have an idea on how I could encapsulate this information in HATEOAS.
I was thinking to something like:
POST /item/42/activate
200 Ok
Content-Type: application/json
{
"suggested-action": "check-censure-panel",
"censure-reason": "censored (gambling)",
"_embedded": {
"foo.item": {
"id": 42,
"title": "Lorem Ipsum",
"status": "ACTIVE",
"body": "Very long text."
"_links": {
"self": {
"href": "/item/42"
},
"permalink": {
"href": "/item/42/permalink"
}
}
}
}
But the problem is that every suggested action is heterogeneous for extra attributes, another example may be:
"suggested-action": "go-to-checkout",
"product-order": 424242100,
They don't have a common interface, so I can't make a a vnd.foo.suggestedAction+json type.
What is the best way to design this response?
The next action is a state transition, and you seem to be using HAL so any state transitions should be presented as HAL.
Clients of your app need to react to what state transitions your app provides. So one very simple thing you could do is send a Location header to the next resource the app should present. You could even 302 redirect them there instead of 200'ing them with the updated resource.
You could provide the next action as a link...and not necessarily a HAL link. You could do it as a Link header (https://www.rfc-editor.org/rfc/rfc5988) but i think that would be weird, i just bring it up to knock home the point that your app needs to tell your client about a link.
You seem to want to use custom media types, but you could use profile links (https://www.rfc-editor.org/rfc/rfc6906) and mix in a profile into your vnd.foo type. You can stick to your vnd.foo type and just have it defined that there is an optional suggested-action link relationship. The problem in your example is you're defining it with data fields, but use a link:
{
"id": 42,
"title": "Lorem Ipsum",
"status": "ACTIVE",
"body": "Very long text."
"_links": {
"self": {
"href": "/item/42"
},
"permalink": {
"href": "/item/42/permalink"
},
"x:suggested-action" : {
"href" : "/path/to/best/action"
}
}
the client can follow that link, present the user with an option to follow that link, or ignore it. In the middle case, it's nice if your app provides some context to the user, like a title field:
"x:suggested-action" : {
"href" : "http://path/to/check/censure/panel",
"title" : "Check Censure Panel"
}
Also you can give a hint as to the resource the app can expect:
"x:suggested-action" : {
"href" : "http://path/to/check/censure/panel",
"title" : "Check Censure Panel",
"type" : "vnd.censure.panel/json"
}
I personally don't like doing that as i like my client to react to whatever i send them, but it's useful when you give multiple suggested actions:
"x:suggested-action" : [
{
"href" : "http://path/to/check/censure/panel",
"title" : "Check Censure Panel",
"type" : "vnd.censure.panel/json"
},
{
"href" : "http://path/to/checkout",
"title" : "Start Checkout",
"type" : "vnd.checkout/json"
}
]
now the app can decide based on well defined media types which of the suggested actions it wants to do, present, or ignore.