expected conditions with JSON objects - protractor

I am making an API call which returns a JSON Structure in the response:
{
"tags": [],
"scope": "all",
"tenant_id": "0",
"version": 1,
"type": "tenant",
"description": "",
"name": "3",
"body":{
"settings": {},
"tenant_id": "2",
}
}
When I am trying to compare
expect(res.body.name).toBe(3);
or
expect(res.body.name).toEqual(3);
It fails and gives follwoing error:
Expected '3' to be 3.
or
Expected '3' to Equal 3.

Your are equating string '3' to number 3, that is the reason for the failure. You can use the following code:
expect(res.body.name).toEqual("3");
OR
expect(res.body.name).toBe("3");

"name": "3", makes it sound as though expect(res.body.name).toEqual('3'); should work since "3" is a string.
Also in that same vein:
expect(res.body.name).toBe('3'); in case your code style prefers === checks over ==
expect(Number(res.body.name)).toEqual(3); in case you need to be expecting the number 3 regardless of the exact type of 3.
If the api response was "name": 3,, your tests would be good as is, but it seems as though the implementation has it stored as a string. Either file a bug if it needs to be a number, have your expectations be strings as well, or convert the api response to a number before asserting.
I don't think you need to expect literally '3', just 3 the string rather than 3 the number.

Related

Woocommerce REST API display attributes meta_data as slugs

I rely on the Woocommerce REST API for a couple different purposes—one is through the shipping platform ShippingEasy and the other is a custom solution to get order information into a google spreadsheet. When retrieving the order information, I have noticed that variable product attributes are coming over as the slugs and not as the case sensitive names.
To make sure there were no bugs or conflicting plugins I performed a clean install, added a couple test products, then pulled the orders using postman via the API. Sure enough Woocommerce serves the slug as the value instead of the name. Here is a small sampling of what is returned from the GET
"line_items": [
{
"id": 3,
"name": "Test Product - Black, Small",
"product_id": 26,
"variation_id": 29,
"quantity": 1,
"tax_class": "",
"subtotal": "6.00",
"subtotal_tax": "0.00",
"total": "6.00",
"total_tax": "0.00",
"taxes": [],
"meta_data": [
{
"id": 29,
"key": "pa_color",
"value": "color-black"
},
{
"id": 30,
"key": "pa_size",
"value": "size-small"
},
{
"id": 31,
"key": "Clip ($5.00)",
"value": "Upgrade"
}
],
"sku": "TEST",
"price": 6
}
],
As you can see, under "meta_data", "key" (the attribute name) is showing the slug and "value" (selected attribute term) is also showing the slug. You may note "id" 29 and 30 are both global attributes, so it is appending the pa_ value to the "key" as well. What is interesting is that if you create the attribute locally (within the product listing), the GET shows the "meta_data" "key" as the slug, but the "value" will show as the case sensitive name. You may note that "id" 31 is displaying both the "value" and "key" with the case sensitive names—these are coming from the Add-ons plugin.
It seems that the meta_data "key" and "value" should be able to display as the case sensitive name. Is it possible this could be resolved using a function within functions.php?
It now looks like the API provides display_key and display_value within the meta_data, which returns the name instead of the slug for each. Oddly enough this is not yet in the API documentation and must be a recent addition, which I stumbled across from testing a random GET request.

Creating a domain in Plesk's REST API

So, experimenting with Plesk's REST API (available as of version 17.8) for a project at work, and I'm starting to get a feel for it. I've been trying to experiment with adding a domain, but it's been giving me errors when I have to specify the hosting type.
The request body itself is as follows:
{
"name":"example.com",
"hosting_type":"virtual",
"description":"Description goes here"
}
This gets the following cryptic response:
{
"code": 1014,
"message": "htype\/vrt_hst is specified but there is no hosting\/vrt_hst"
}
Per the documentation provided at /api/v2/swagger.yml, any of the following values should be allowed: virtual, standard_forwarding, frame_forwarding, none
No matter what I put in, however, I get a variant of the response above (htype\/{type} is specified but there is no hosting\/{type}).
At this point I'm kind of stuck; I'm not sure what to check, and any references when I try to look up the error code go to references on Plesk's XML API instead. What's the missing link here needed to get the request to work?
It looks like system user is not specified - hosting_settings. Try to add domain with full json request. Here is example:
{
"name": "example.com",
"description": "My website",
"hosting_type": "virtual",
"hosting_settings": {
"ftp_login": "test_login",
"ftp_password": "test_pwd"
},
"base_domain": {
"id": 7,
"name": "a10-52-41-48.qa.plesk.ru",
"guid": "b623e93d-dc72-4102-b5f0-ded427cf0fb1"
},
"parent_domain": {
"id": 7,
"name": "a10-52-41-48.qa.plesk.ru",
"guid": "b623e93d-dc72-4102-b5f0-ded427cf0fb1"
},
"owner_client": {
"id": 7,
"login": "a10-52-41-48.qa.plesk.ru",
"guid": "b623e93d-dc72-4102-b5f0-ded427cf0fb1",
"external_id": "b623e93d-dc72-4102-b5f0-ded427cf0fb1"
},
"ipv4": [
"212.192.122.46"
],
"ipv6": [
"2002:5bcc:18fd:c:123:123:123:123"
],
"plan": {
"name": "Unlimited"
}
}
Examples for REST API https://app.swaggerhub.com/apis/plesk/api/v2#/Domains/post_domains

REST API design for specifying value options

Given a resource like:
GET: /api/examples/1
{
"id": 1,
"direction": "North"
}
Which also supports POST, PUT, how should the possible values for "direction" be specified?
Additionally, is there a solution which allows the consumer to know which values will be available if those values are contextual? e.g. if the example is made more complicated:
GET: /api/examples/
{[
{
"id": 1,
"startLocation": "Kentucky, USA",
"direction": "North"
}
{
"id": 2,
"startLocation": "North Pole",
"direction": "South"
}
}]
(with something vaguely like):
"options": [
{
"value": "North",
"validWhen": "startLocation !== `North Pole`"
},
{
"value": "East",
"validWhen": "true"
},
...
]
Is there a better solution than another resource linked from each example which returns the currently valid options? If not, how does the consumer know that changing "startLocation" changes the valid set of values for "direction"?
I think what you might be looking for is a JSON-Schema. This allows you to strictly describe what options are available in your JSON document, and you can link to the document using a describedBy link.
To expand on what #Justas said in his comment, if I understand your requirements correctly, your resource might look something like:
GET /examples/1
{
"startLocation": "Kentucky, USA",
...
"_links": {
"travel-north": "/some/url",
...
}
}

Validate referential integrity of object arrays with Joi

I'm trying to validate that the data I am returned it sensible. Validating data types is done. Now I want to validate that I've received all of the data needed to perform a task.
Here's a representative example:
{
"things": [
{
"id": "00fb60c7-520e-4228-96c7-13a1f7a82749",
"name": "Thing 1",
"url": "https://lolagons.com"
},
{
"id": "709b85a3-98be-4c02-85a5-e3f007ce4bbf",
"name": "Thing 2",
"url": "https://lolfacts.com"
}
],
"layouts": {
"sections": [
{
"id": "34f10988-bb3d-4c38-86ce-ed819cb6daee",
"name": "Section 1",
"content:" [
{
"type": 2,
"id": "00fb60c7-520e-4228-96c7-13a1f7a82749" //Ref to Thing 1
}
]
}
]
}
}
So every Section references 0+ Things, and I want to validate that every id value returned in the Content of Sections also exists as an id in Things.
The docs for Object.assert(..) implies that I need a concrete reference. Even if I do the validation within the Object.keys or Array.items, I can't resolve the reference at the other end.
Not that it matters, but my context is that I'm validating HTTP responses within IcedFrisby, a Frisby.js fork.
This wasn't really solveable in the way I asked (i.e. with Joi).
I solved this for my context by writing a plugin for icedfrisby (published on npm here) which uses jsonpath to fetch each id in Content and each id in Things. The plugin will then assert that all of the first set exist within the second.

GET Values from a custom field via JIRA REST API

I would like to GET all drop down options for a custom field. For system fields, I use the following URI:
http://localhost:8080/rest/api/2/project/XXXX/components
(for components, versons, etc. Basically system fields), so I tried the following for a custom field
http://localhost:8080/rest/api/2/project/XXXX/customfield_10000
and got a 404 error. I'm not sure what I'm doing wrong as I've been googling for the past 19 hours. The best I search result I got was the following documentation: JIRA Developers Documentation
Please assist, I'm not sure What I'm missing
You can get that information either from the createmeta or editmeta REST resources.
Use editmeta if you want to retrieve the available options when editing a specific issue. E.g.
GET /rest/api/2/issue/TEST-123/editmeta
Use createmeta when you want to retrieve the options for a project in combination with an issue type. E.g.
GET /rest/api/2/issue/createmeta?projectKeys=MYPROJ&issuetypeNames=Bug&expand=projects.issuetypes.fields
The customfields with options will be returned like this:
"customfield_12345": {
"schema": {
"type": "string",
"custom": "com.atlassian.jira.plugin.system.customfieldtypes:select",
"customId": 12345
},
"name": "MySelectList",
"allowedValues": [
{
"self": "http://jira.url/rest/api/2/customFieldOption/14387",
"value": "Green",
"id": "14387"
},
{
"self": "http://jira.url/rest/api/2/customFieldOption/14384",
"value": "Blue",
"id": "14384"
}
]
}