I'm new to API's but made a bit of headway today in integrating a call to the Duedil (UK Company information directory).
I'm doing this in Salesforce using Buttons
My first call is an easy search on Account Name in Salesforce
CALL 1:
http://api.duedil.com/open/search?q={!Account.Name}&api_key=MY_API_KEY
"Arjo Fine Paper" is the Account.
The response returned is:
{
"response":
{"pagination":"http:\/\/api.duedil.com\/open\/search?query=Arjo+Fine+Paper&total_results=3&limit=5&last_result=1",
"data":[
{
"company_number":"**00961440**",
"locale":"United Kingdom",
"name":"Arjo Wiggins Fine Papers Limited",
"uri":"http:\/\/api.duedil.com\/open\/uk\/company\/00961440.json"
},
{
"company_number":"01870033",
"locale":"United Kingdom",
"name":"Arjo Wiggins Fine Papers Export Limited",
"uri":"http:\/\/api.duedil.com\/open\/uk\/company\/01870033.json"
},
{
"company_number":"00683415",
"locale":"United Kingdom",
"name":"Arjo Wiggins Fine Papers Holdings Limited",
"uri":"http:\/\/api.duedil.com\/open\/uk\/company\/00683415.json"
}
]
}
}
What I want to do is parse the first Company number and then display the results
e.g. "https://www.duedil.com/company/00961440"
Do I embed Call 1 in some JS that can parse out the answer from Call 1?
Thanks for any help/steers.
Try to have a look at the Salesforce doc ( here ) for parsing the JSon Strings or Serializing the information back to some Collection of Objects (or Wrapper classes).
You may also have a look at serializing your information (in form of Collection, Object or a String) using JSON.serialize() method while to get the information back (Collection, Object or String) you need to use JSON.desrialize() by typecasting it.
Related
I need games under $10 on Steam. How should an inquiry be made for this?
api link here
In the link here, I can only fetch games under $10 as json, but there is no information such as game id prices.
I need these. Thank you
$steamUnder20 = Http::get("https://store.steampowered.com/search/results?maxprice=20&cc=tr&l=turkish&json=1");
$resultUnder = $steamUnder20->json();
Result :
"desc": "",
"items": [
{
"name": "Black Desert",
"logo": "https://cdn.akamai.steamstatic.com/steam/apps/582660/capsule_sm_120.jpg?t=1658233501"
},
{
"name": "Slime Rancher",
"logo": "https://cdn.akamai.steamstatic.com/steam/apps/433340/capsule_sm_120.jpg?t=1651003375"
},
Steam offers an endpoint called appdetails that allows you to fetch a whole lot information about one or multiple comma-separated game IDs specified in the appids parameter:
http://store.steampowered.com/api/appdetails?appids=1,2,3
According to the inofficial documentation by RJackson in the Team Fortess wiki you can specify the values you need in the filter parameter, otherwise the response will include all basic details: https://wiki.teamfortress.com/wiki/User:RJackson/StorefrontAPI#appdetails
In your case I suggest iterating through your response and parsing the gameID from the logo URL and using them collectively for the appdetails endpoint to fetch all the information.
Additionally, you can also use the cc parameter to specify a currency and the l parameter to localise the response. These parameters are not documented in the documentation by RJackson.
just want to know if and how I can parse a HTTP response with a dynamic name in a JSON?
I used the Azure Management API to receive the managed identities (system- and user assigned managed identities) to receive all managed identities.
With a foreach I am iterating the results.
If a resource has a system assigned managed identity and user assigned managed identity, the response looks like this:
{
"principalId": "<principalId1>",
"tenantId": "<tenantId>",
"type": "SystemAssigned, UserAssigned",
"userAssignedIdentities": {
"/subscriptions/<subscriptionId>/resourcegroups/<resourceGroupName>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<userAssignedIdentitiesName>": {
"principalId": "<principalId2>",
"clientId": "<clientId>"
}
}
}
Now, I would like to get the <principalId2>.
Unfortunately, the Name of the object is dynamic related to the scope of the resource /subscriptions/<subscriptionId>/resourcegroups/<resourceGroupName>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<userAssignedIdentitiesName>.
How can I parse the JSON to receive the needed <principalId2>?
For all other responses I can easily use the Data operations Parse JSON with the payload I inserted from the HTTP response.
Is there a way to use a wildcard? Otherwise, could I somehow just select the first object of userAssignedIdentities to receive the needed value?
Ok, this should work for you. This is the flow I tested with ...
Initialise JSON
Your JSON as a string, how you do that in your solution may differ slightly.
Initialize XPath Result
Defined as an Array and the expression is ...
xpath(xml(json(concat('{ root: ', replace(variables('JSON'), 'PrincipalId', 'principalId'), '}'))), '(//principalId)[2]')
Initialize Result
A bit more work again but defined as a String and the expression is ...
array(xpath(xml(base64ToString(variables('XPath Result')[0]?['$content'])), '//text()'))[0]
The end result should be your value ...
I'm just doing the preparation for an integration with EasyPost's Shipping API, which will be server side C#, but we always build a PostMan collection for new integrations, so that we can test data separately from the application if there's an issue.
While I do love the fact that EP provide C# libraries and examples, I'm struggling to find anything that just gives me a list of required headers and the raw JSON format for the body of any requests. It feels a bit like they're just being a little too helpful.
I'll be looking at the Orders endpoint probably.
I've got an account, I've checked all their documentation and searched the internet but haven't found anything so I'm hoping I'm not the first developer to want to use a client application for testing outside my code.
Update:
EasyPost now does have a public workspace https://www.postman.com/easypost-api
with at least 1 public collection
The curl examples are basically the same as json:
For the Address creation example:
-d "address[street1]=417 MONTGOMERY ST"
is the equivalent of
{ "address": { "street1": "417 MONTGOMERY ST" } }
(you might have to escape some characters to be valid json).
Check out How to stimulate cURL request to a request using postman for postman with HTTP Basic Auth.
EasyPost does not provide a public Postman collection; however, here is an example of a shipment Postman body (raw) that could be used. You can adjust the values, actions, objects, etc to your needs.
Using the following, you shouldn't need to pass any headers. You'll pass your API key under the username field with the Basic Auth authorization type.
{
"shipment": {
"to_address": {
"id": "adr_123..."
},
"from_address": {
"id": "adr_123..."
},
"parcel": {
"id": "prcl_123..."
},
"carrier_accounts": {
"id": "ca_123..."
},
"options": {
"address_validation_level": "0"
}
},
"format": "json",
"controller": "shipments",
"action": "create"
}
I'm trying to ascertain what best practice might be for returning a JSON response for a Restful API call. I've read multiple blog and tutorial articles that offer different opinions.
One approach I've seen proposes that any Restful call return a JSON response that includes both meta data and result data, like the representation shown below:
// response to a GET that returns an array of elements
{
"status": "success",
"count": 2,
"type": "LoadServingEntity",
"results":[ {
"lseId": 2756,
"name":"Georgia Power Co",
"code":"7140",
"websiteHome":"http://www.georgiapower.com/"
}, {
"lseId":1,
"name":"City of Augusta",
"code":"1000",
"websiteHome":null
}]
}
// an response that reports an API error
{
"status":"error",
"count":2,
"type":"Error",
"results":[{
"code":"NotNull",
"message":"An appKey must be supplied",
"objectName":"requestSignature",
"propertyName":"appKey"
}, {
"code":"NotNull",
"message":"An appId must be supplied",
"objectName":"requestSignature",
"propertyName":"appId"
}]
}
Other articles poo-poo this approach. I'm about to start a new API project and I'd like to get feedback from experts about the best approach on this subject.
TIA
Check out http://jsonapi.org/ which provides a recommended specification for building a JSON API. The response should include both the data and metadata
I'm relatively new to REST but I've been doing my homework on how RESTful should be. Now I'm trying to create a RESTful api implementing a JSON+HAL serializer for my models which have relationships with other models.
Example models in python:
class Category(Model):
name = CharField()
parent = ManyToOneField(Category)
categories = OneToManyField(Category)
products = ManyToManyField(Product)
class Product(Model):
name = CharField()
price = DecimalField()
related = ManyToManyField(Product)
categories = ManyToManyField(Category)
lets suppose we have a category "catalog" with a sub-category "food" with products "burger" and "hot-dog" which are both related.
First question. Categories and products should be resources so they need an URI, should I implement an uri field in my model and store it in the DB or somehow calculate it at runtime, what about multiple identifiers(URIs)?
Second question. Discoverability, In Hal format what should "GET /" and diferent nodes return to make the api easily self discoverable.
{
"_links":{
"self":{
"href":"/"
},
"categories":[
{
"href":"/catalog"
}
]
}
}
Third question. Add as properties, embed or link. Example "GET /catalog/food":
{
"_links":{
"self":{
"href":"/catalog/food"
}
},
"name":"food",
"parent":"/catalog",
"categories":[],
"products":[
"/products/burger",
"/products/hot-dog"
]
}
{
"_links":{
"self":{
"href":"/catalog/food"
},
"parent":{
"href":"/catalog"
},
"categories":[
],
"products":[
{
"href":"/products/burger"
},
{
"href":"/products/hot-dog"
}
]
},
"name":"food"
}
{
"_links":{
"self":{
"href":"/catalog/food"
}
},
"name":"food",
"_embedded":{
"parent":{
"_links":{
"self":{
"href":"/catalog"
}
},
"name":"catalog",
...
},
"categories":[
],
"products":[
{
"_links":{
"self":{
"href":"/products/burger"
}
},
"name":"burger",
...
},
{
"_links":{
"self":{
"href":"/products/hot-dog"
}
},
"name":"hot-dog",
...
}
]
}
}
Fourth question. How deep should I go when returning structures. Example "GET /catalog
{
"_links":{
"self":{
"href":"/catalog"
}
},
"name":"catalog",
"parent":null,
"categories":[
{
"name":"food",
"parent":{...},
"categories":[],
"products":[
{
"name":"burger",
"price":"",
"categories":[...],
"related":[...]
},
{
"name":"hot-dog",
"price":"",
"categories":[...],
"related":[...]
}
]
}
],
"products": []
}
About 1st question: I wouldn't store the URIs in the DB. You can easily calculate them inside your controller in runtime, and it's of controller's responsibility to care about URIs. This way you keep your model and your API decoupled, and should you decide to change the API structure in the future, you won't need to update your whole database with the new URIs.
About multiple identifiers, I'm not sure what the question is, but again, in my opinion, it has nothing to do with the DB, it's the routing and the controllers who should care about how to deal with any URIs.
About 2nd question: First of all, as a side note: I would keep the word categories as part of the URI. For example, I 'd have http://domain.com/api/categories/catalog/food. This way, you make your API more descriptive and more "hackable", meaning that user should be able to remove the /catalog/food part and expect to receive a collection with all the available categories.
Now, about what GET should return to allow discoverability: I think it's already being made clear from your URI structure. When user hits GET /categories he expects to get a list with the categories (the name and URI for each, to keep it lightweight), and when he follows one of the URIs like GET /categories/catalog he should receive the resource catalog which is a category. Likewise, when he wants to GET /products/burger, he should receive a product resource with all the attributes you have in your model. You may want to check this example about the structure of your responses.
About 3rd question: Again, the same example can help you form the structure. I think your 2nd way of response is closer to that, but I would also add a name field, not only the href.
About 4th question: When the GET request expects a collection of resources (like GET /categories) I would suggest providing only the necessary for each resource, that is, the name and the URI for each and only when user follows the desired URI, he can receive the rest information.
In your example, catalog is a resource, so on GET /categories/catalog I would include of course the name of the resource (catalog) and its self link, and for parent, sub-categories and products that are related to it, I would just provide the name and the URI for each, to keep it light. But: This was a general thought about designing APIs. In your actual problem, you should decide depending on your specific business problem. I mean, if your API is about a restaurant menu with categories and dishes, you may want to include the price, or a small description even when responding not for the actual product but for a collection of products, because probably for your users, that's an important information. So generally, provide all the necessary info (you only know what are these for your problem) when responding about a list of resources, and provide all the details of the resource when responding about a specific resource.
I would store something in the DB and calculate the URI at Runtime. That way if you move boxes it's not static.
Create a 'bookmark' page. The page we created was just a list of links with their rels. I believe HAL defines that specifically. The bookmark page was the only page other pages needed to know about
Not sure about this
How deep you go is up to you. There is a big debate now at my place of work for fine grain vs course grain. I'm going to do fine grain with small resource to keep the api simple, but then use the Expand-ability concept. It's a combination ofthe idea of composite resources defined on pg 35 of Subbu’s REST book and the expand concept used by Netflix. http://developer.netflix.com/docs/REST_API_Conventions