In a NodeJS based project, the Swagger that comes with loopback-component-explorer (version 2.7.0) doesn't show the "Parameters" in the HTML page in which we can provide the required params for the Rest endpoints, regardless the http verb (e.g. GET, POST, PATCH etc). Must the remoteMethod(...) definition follow some Swagger requirements?
Thanks.
I've figured out.
When defining the Loopback remoteMethod(...), the option "http.source" for "accepts" should be set to anything different than "req", "res" and context (e.g "body", "form", "query" and "path").
Related
I'm trying to figure out how to get the route for an HTTP triggered Azure Function within an ARM template.
Thanks to a blog post I managed to find out the listsecret command, but when trying to execute this action via powershell, the output doesn't give me the trigger_url I was expecting. The URL does not comply with the configured route of the function, and shows the default trigger if no route would have been configured.
Any way I can get a hold of the configured route instead since I can't seem to use the trigger_url.
My configured route has got parameters in the path as well, e.g.:
{
"name": "req",
"type": "httpTrigger",
"direction": "in",
"authLevel": "function",
"methods": [
"POST"
],
"route": "method/{userId}/{deviceId}"
}
The output of listsecrets is:
trigger_url: https://functionapp.azurewebsites.net/api/method?code=hostkey
Is there any other way to extract the host key and route?
Try playing with the API version, but I would suspect that this is not possible as of now.
Currently, the only way to get the route is by reading the function.json file and parsing that information out, which you can do by using Kudu's VFS API.
For the keys, I would actually recommend using the key management APIs instead of listSecrets. As the latter is meant to address a small set of scenarios (primarily to enable some internal integrations) where the key management API more robust API and will continue to work with different secret storage providers (e.g. Azure Storage, which is what is used when slots are enabled and will eventually become the default).
My requirement is to clear all activities on a notification feed.
Based on this stackoverflow question I understand that there is an undocumented REST API to delete a feed and the dashboard truncate feed functionality uses it.
I tried to replicate the call with the same parameters as dashboard:
DELETE /api/v1.0/feed/notification/f8fa1d12-594a-4b2b-ac58-23c912d1335a/?api_key=...&location=unspecified
Host: api.getstream.io
Authorization: notificationf8fa1d12-xxxx-xxxx-xxxx-23c912d1335a writetoken
stream-auth-type: simple
X-Stream-Client: stream-javascript-client-browser-unknown
Cache-Control: no-cache
Tried to use the same but am getting this error message:
{
"code": null,
"detail": "url signature missing or invalid",
"duration": "6ms",
"exception": "AuthenticationFailed",
"status_code": 403
}
Is this the right way to use this API?
I am using this from Java code and believe that the Java client doesn't have this functionality built in.
There's two ways to do this. You can do it manually from the explorer on the dashboard. Search for the feed, select an activity and press the truncate feed button. This is the easiest way to do this if manually doing this is sufficient.
It's also possible like you found to use the delete API endpoint to do it programmatically. This endpoint is not built in to most clients, including the Java client. The URL and HTTP verb that you used should indeed work.
From what I can tell from your headers and the response it seems like you are having an issue with supplying a correct signature. The easiest way to do this correctly is to use the built in methods in the library you're using to generate them. I'm not an expert in the Java library, but it seems like these methods are inside the StreamRepoUtils class.
i'm using the Box View API to convert a PDF file to HTML, i'm using the /documents/{id}/content.{extension} section.
The response for this GET call is a .zip file, however i don't know how to retrive it and make downloadable.
Also note that i'm using node.js.
Thanks for your help
You can set your own webhook URL that will be called by Box when your document status changes (one POST on your webhook for "document.viewable", and one for "document.done" plus one "document.error" if an transformation error occured).
Just listen to the "document.done" status and download the assets then. Format that is posted to the webhook you have set looks like :
[{
"type": "document.done",
"data": {
"id": "4cca28f1159c4f368193d5014fabc16e"
},
"triggered_at": "2014-01-30T20:33:04.798Z"
}]
Beware of the docs and check the format programatically. Their API docs are often no quite correct and they post multiple webhooks at the time i'm writing (which is a bug i've reported).
For more info and Box View API docs
I need to get only those SmartCollections that are imitating some kind of category of products e.g. Pants, Shirts, Shoes. But there is also collections like "All Products" or "Available on local store". What I need to get via API are only those spesific categories and nothing else.
So is there any way to set some kind of metafield or alternative to SmartCollections so I could filter via API only collections I need?
Of course one(and really bad) way to do this is to hard code list of not wanted collections, but this solution isn't very dynamic :/
I am using this package froatsnook:shopify from atmospherejs.com.
Here is Shopify's API documentation about SmartCollections: SmartCollection
Okay, I managed to do this eventhough API disagrees with me. With this Chrome extension you can use metafields also with SmartCollections: http://shopifyfd.com/
And then you just have to create new function for this new endpoint via build in functionality provided by froatsnook:shopify like this:
Shopify.API.define({
"name": "getSmartCollectionMetafieldsById",
"method": "GET",
"path": "/admin/smart_collections/#{collection_id}/metafields.json",
"returns": "metafields",
"description": "Get a single smart_collection metafields by its ID"
});
And voilá! Now you can include/exclude SmartCollections via API by using metafields!
How do you update a SharePoint 2013 wiki page using the REST API?
Three permutations:
Reading an existing page (content only)
Updating an existing page
Creating a new page
For reading an existing page, of course I can just to a "GET" of the correct URL, but this also brings down all the various decorations around the actual data on the wiki page-- rather than fish that out myself, it would be better if there was a way to just get the content if that is possible.
Are there special endpoints is the REST API that allow for any of these three operations on wiki pages?
As stated in GMasucci's post, there does not appear to be a clean or obvious way of instantiating pages through the REST API.
You can call the AddWikiPage method from the SOAP service at http://[site]/_vti_bin/Lists.asmx. This is an out of the box service that will be accessible unless it has been specifically locked down for whatever reason.
To read the content of a wiki page through the REST API, you can use the following endpoint:
https://[siteurl]/_vti_bin/client.svc/Web/GetFileByServerRelativeUrl('/page/to/wikipage.aspx')/ListItemAllFields
The content is contained within the WikiContent field. You may want to add a select to that URL and return it as JSON to reduce the amount of data getting passed over if that is a concern.
As for updating the content of an existing wiki page, it is not something I have tried but I would imagine it's just like populating another field through the REST API. This is how I would expect to do it:
Do a HTTP POST to the same endpoint as above
Use the following HTTP headers:
Cookie = "yourauthcookie"
Content-Type = "application/json;odata=verbose"
X-RequestDigest = "yourformdigest"
X-HTTP-Method, "MERGE"
If-Match = "etag value from entry node, returned from a GET to the above endpoint"
Post the following JSON body
{
"__metadata": { "type": "SP.Data.SitePagesItem" },
"WikiField" : "HTML entity coded wiki content goes here"
}
The interim answer I have found is to not utilise REST, as it appears to not be
fully documented
fully featured
supported across Sharepoint 2013 and On-line in the same way
So my current recommendation would be to utilise the SOAP services to achieve the same, as these are more documented and easily accessible.