I'm trying to fetch the value of an item in a metadata list on a page in Confluence using the REST API. So far I have been able to extract fetch the body using a URL like this
https://acme.com/rest/api/content/105088446?expand=body.storage
(documentation here: https://developer.atlassian.com/confdev/confluence-server-rest-api/expansions-in-the-rest-api)
Or the full contents of the metadata list macro like this
https://acme.com/rest/api/content/105088446/history/10/macro/id/c65d00a3-49e2-40e5-a032-50b6c187d968
(documentation here: https://docs.atlassian.com/confluence/REST/latest/#content)
But neither of these are satisfactory. The first leaves a lot of parsing, the second requires I define the version of the page and even then returns the whole table that needs to be parsed.
I'm not sure if you are referring to the page properties (Page Properties Macro). If so you could try the masterdetails REST service.
rest/masterdetail/1.0/detailssummary/lines
You can use the REST API Browser to discover the parameters (note that this is part of the non-public API, so you need to check of the "Show only public APIs" checkbox to see it in the list).
There is a similar question on Atlassian Answers.
Related
I'm struggling with how to find the content status of a page in Confluence.
My end goal is to be able to change/update via the API.
I've added the list of statuses already in the Manage space section. I have successfully pulled the content of a page as well as its properties, but I can’t seem to find where the content status is stored.
Here is the URI I'm using:
https://MyDomain.atlassian.net/wiki/rest/api/content/145468621376?expand=space,body.storage,view,version.status,container,extentions
That Status is not present in OOB Confluence, so I suppose it is some third-party app from Atlassian Marketplace and you need to check with their documentation how to interact with it.
Of course, you can directly use the REST API to get page content as a string (HTML) and change its content, e.g. using Python (Atlassian Python API’s documentation)
Page actions
def my_page = confluence.get_page_property(page_id, page_property_key)
def new_body = my_page.body.replace("<macro .....>", "<new status in HTML>")
confluence.update_or_create(parent_id, title, new_body, representation='storage')
Finally sorted it out with the help of Atlassian support. If their documentation was correct it would've been super easy to do this.
https://developer.atlassian.com/cloud/confluence/rest/api-group-content-states/#api-group-content-states
Heres the catch. when you GET the status you have to add on the parameter for status even though its optional. so your get string needs to look like this:
your-domain.atlassian.net/wiki/rest/api/content{id}/state?status=current
Same goes for setting the new state. You have to add on the status parameter to the uri.
Link to the HATEOAS This is the link to the Hateoas article (snapshot below) where the identifiers of the resource is part of the URL i.e. 12345. Here the API response has the final API relative URL i.e. /accounts/12345/deposit and the client just needs to hit it.
Link to the Github Users API This is the link to the Github API (snapshot below) where there are lots of placeholders for identifiers. How will clients modify these URLSs and add a value in these placeholders? For example, {/gist_id}, {/other_user}.
Isn't passing the URL with id value instead of placeholder better? Why and when to rely on different clients to add values in these placeholders?
Hypertext as the engine of application state (HATEOAS) is a bit more than just the usage of links. In essence it enforces the interaction model that is used on the Web for two decades quite successfully. On the web a server usually "teaches" clients (browsers) to achieve something via the help of link relations, that can be used to automatically download related resources or give a hint on the reference resource, and Web forms, that define the syntax and semantics of each of the respective supported (input) elements, i.e. a text field, an option element to select one or multiple choices, a drop down or even a slider widget. Based on the affordance of each of the elements a client knows i.e. that a button wants to be clicked or pressed while a text fields wants some user input and stuff or a link annotated with the prefetch link relation name may be downloaded automatically once the current page finished loading as a client might invoke it next or a preload link relation might instruct a user agent to load the referenced resource early in the current page loading process.
The form not only teaches a client about the supported fields a resource has but also about the target URI to send the request to, the HTTP method to use wile sending the request as well as the media-type, which in the case of Web forms is usually implicitly set to application/x-www-form-urlencoded.
In an ideal world a client just uses the information given by the server. Unfortunately, the world isn't perfect and over time people have come up with plenty of other solutions. Among one of them is URI templating that basically allows clients to use a basic URI and fill out certain placeholders with concrete values. As making use of templating requires some knowledge of the URIs intention or the parameters you need to pass, such capabilities make only sense as part of media-type support.
Plain JSON (application/json) has by default no support for URIs whatsoever and as such a user agent receiving a plain JSON payload might not be able to automatically replace a template URI with a concrete one out of the box. JSON Hyper-Schema (application/schema+json) attempts to add link and URI template support to plain JSON payloads. A user client though needs to be hinted with the appropriate media-type in order to automatically resolve the full URI. As such, the user agent also has to support that respective media type otherwise it won't be able to process the document (resolve the template URI to a real URI) successfully.
JSON Hypertext Application Language a.k.a HAL JSON also supports URI templates for links. application/collection+json does support two kinds of templates - query templates and objects-template. The primer one is similar to a URI template by allowing to append certain query parameters to the target URI upon sending the request while the latter one allows to define a whole object that contains all the input elements used to add or edit an item within the collection. JSON-LD does not really support URI templating AFAIK though it uses the concept of a so called context where certain terms can be used to abbreviate URIs. As such something like name can be used within the context for a URI like http://schema.org/name.
As you can hopefully see, the support for URI templating depends on the media-type used for exchanging data. In the case of the outlined github example GET /users/:username this more or less resembles a typical Web API documentation, similar as it is done in a Swagger API documentation, that unfortunately has hardly anything to do with HATEOAS.
For your top example (banking), you should absolutely include the complete URL, with account numbers (IDs), so that the client does not need to translate/substitute anything. This is the most common scenario with HATEOAS. However, GitHub does have those "placeholders" for endpoints that could contain multiple values. You can't include the "following_url" for every user in the response, it's not practical. So you have to determine the "other_user" value another way and make the substitution. Personally, I haven't even had this use case with any of my applications and all of my HATEOAS URLs resemble you first example (though I prefer full URLs not relative). Unless you have specific cases like GitHub does, it's not necessary to use any of these placeholders. Even GitHub only uses that where they could be multiple values. For fixed value URLs, they have the username (like your account number) in the URL ("octocat").
According to me we should not give the direct url in the body
We should always parameterized the api and get details form there.
In simple case if Id of data change than every time data need to update for detail url.
Else if it’s dynamic you will never face this issue.
And this also come under best practices.
I created a function in IBM cloud which displays some JSON data when invoked. I am trying to figure out how client can consume this information. I am unable to find any information on net. I would like to preferable access the function through HTTP request or if that is not possible do it through some python script. Does anyone have more information on how this can be achieved?
Depending on the nature of your action/function, there are different ways to call it. In any case, you can find the required information about URL (and API key), by clicking the action in the action panel, and select 'endpoints' from there.
If you created a 'plain' action (i.e. one that accepts JSON and returns JSON), you will have to use the API key shown on the panel mentioned above. You can find it -- and the URL to use, in the 'Rest API' section. At the bottom of this page, there is also a complete curl command, which you can just copy & paste (and where you only need to insert the API key).
In case you created a web action (see here for details: https://console.bluemix.net/docs/openwhisk/openwhisk_webactions.html#openwhisk_webactions) , you can call it anonymously. The URL for that is different than the one referred to above -- you can find it in the 'web actions' section of the 'Endpoints' tab.
My Problem: I want to introduce a new field in JIRA with status information from external REST Service (response is json).
Plan: Every Jira issue has a input field with some reference string. Behind this field there should be a panel, what should display informations from the external REST call (parsing response JSON is required).
Can someone give me some good info pages, how to tell JIRA to call external REST Service?
If you don't want to build it see:
nFeed
HTTP Feed Custom Field
If you want to build it yourself then start by following this tutorial on Creating a custom field type which is to more or less store a basic String within the database. (This would be the reference string)
You then have two options, the first is within the JiraCustomField class override the getVelocityParameters which was taken from How to call a java method from velocity Atlassian Answers question.
Then create a method (fetchValueFromWebService(String val)) that you would call that would contain code to query the REST Service based off the fields value that would be passed in from the velocity template. (E.g. $instance.fetchValueFromWebService($value))
To perform the actual web service call you can use any library you want, just see the Managing Dependencies documentation so it gets included in the plugin. (For example using the Jira Jersey version see this)
Your other option would be to within the view-basictext.vm have it use javascript and perform an AJAX to the web service by calling a function in your own JS file and dump that into a span that you have defined: (See Including Javascript and CSS resources)
<span id="webServiceValue"></span>
<script type="text/javascript">
fetchValueFromWebService($value);
</script>
You would however need to ensure that the webservice has Cross-origin resource sharing (CORS) enabled if you go the AJAX route.
We are attempting to get site logos from the Yodlee API. From the SiteInfo data model (using the SOAP API), there are the following methods that appear to retrieve site logos
siteInfo.getDefaultSiteLogo()
siteInfo.getLocalizedSiteLogos()
getDefaultFavIcon()
The issue is that these methods for the sites we are using (all sites with the AU geography) are returning null.
I am pretty sure this is possible to do, since Yodlee's own fastlink does show logos for sites as you are adding them.
Here are the method call signatures
I am using the soap api through java (using axis 1.4, just like in the sample code) and the API signatures are as follows
SiteAccountManagementService has the method getAllSiteAccounts which has the following signature
com.yodlee.soap.collections.core.accountmanagement.ArrayOfSiteAccountInfo getAllSiteAccounts(com.yodlee.soap.common.UserContext userContext).
Then there is also getCctx, which has the following signature
public com.yodlee.soap.common.CobrandContext getCctx()
None of these methods have a request specifier parameter of any sought
I don't think icons will be returned by default. I believe you need to specify this in your request specifier to get icons/image.
getAllSiteAccounts API is to get the details for the Accounts aggregated by a consumer,
while the information you are looking for(the Logos) are site related not consumer related.
You should use getSiteInfo(under SiteTraversal) to get this specific detail and remember to pass value of siteFilter.reqSpecifier as 128.