Skip navigation
All Places > Alfresco Content Services (ECM) > Blog > Author: gavincornwell

Alfresco has had a REST API for a long time but it organically grew over time as new services and capabilities were added. There were no guidelines defined which culminated in an inconsistent hard to use API.

 

This journey was covered in a Tech Talk Live earlier this year and in a presentation at BeeCon but there hasn't been much coverage of how to use the API, this is the first part of a series of blog posts that aim to introduce you to and provide hands-on experience of using the v1 REST API.

 

We believe a key requirement for a modern day REST API is an OpenAPI Specification (formerly known as Swagger). To provide as much value as possible we decided to manually generate the specification based on the endpoints available in 5.1. Given these hadn't changed since 4.2, customers would have a full specification of the v1 REST API independent of the Alfresco One product. Furthermore, this provides us with a strong API contract that we can use against the next release to ensure no regressions have crept into the product.

 

One benefit you gain from having an OpenAPI Specification for your API is the tooling support, most notably the Swagger UI. We used this to provide customers with the API Explorer, an environment to allow you to experiment with APIs without having to install anything. A majority of the manually written reference documentation on docs.alfresco.com has also been replaced by the API Explorer.

 

api-explorer.png

At the moment the underlying repository is 5.1 so the live API Explorer does not show any of the new APIs added in the recent 5.2.b Early Access Community Release, providing access to all versions is something we're currently discussing. We are also contemplating how to release an API Explorer at the end of every sprint so you can keep track of progress in between releases.

 

In order to follow along with the forthcoming blog posts you'll need an environment to do so, firstly download and install the 5.2.b Early Access Community Release. We'll also be using the Postman client to execute the requests and providing them as a collection. Finally, to setup the API Explorer locally, download the WAR, rename it to api-explorer.war and copy it to $ALF_HOME/tomcat/webapps.

 

Login to Share, go to the Manage Users page and create a user named "test" with a password "test".

 

In the next post we'll get started by looking at navigating the repository, in the meantime, start your server and have a look through the REST API documentation at http://localhost:8080/api-explorer.

A lot has happened since my last post over a year ago!

Full support for metadata is now available in Share, forms are used in several key areas of Share including the datalists feature and the Web Editor product is centered around the forms capabilities.

With forms becoming more prevalent I thought it might be useful to have an easy way to find, run and learn from examples as well as providing utilities to help configure and customize your own forms.

The Forms Development Kit (FDK) was introduced in the 3.3 release, being fairly new it currently consists of a few example form configurations (using 3 custom types and a custom aspect), custom templates & controls and a 'Form Console' utility. One of the example forms is shown in the screenshot below.

Tabbed form example

The intention for the future is to provide working demonstrations of all the example configurations given in the Forms wiki pages, to host 'incubator' controls, provide a testing platform for our internal QA department, show how the forms engine can be customized to suit your needs and of course provide utilities to help you configure your own forms.

The FDK can be accessed from the 3.3 community release download page, full details on how to install and use it are given on the FDK wiki page.
As of this morning the Share web client has very early support for viewing and editing custom metadata.



The FormUI component being implemented as part of the new forms engine is now used in the document details page and the new edit metadata page in Alfresco Share.



The screenshot below shows metadata being viewed and the link that has been modified to launch the new edit metadata page. 



Edit metadata link



Details of the new forms engine can be found here, the only information currently present on the page is the configuration syntax, more information will be published as the development cycle for the next release of Share progresses.



A working example of the form configuration can be found in projects/web-framework-commons/config/alfresco/web-framework-config-commons.xml. Those familiar with configuring custom metadata for the Alfresco Explorer web client will recognise the approach, the usual extension techniques can be used to customise the forms displayed. Just place a file called 'web-framework-config-custom.xml' in the 'alfresco.web-extension' package to override the default configuration or provide your own customisations.



The default configuration produces an edit metadata page as shown below.



Edit metadata page



As mentioned above this is very early support so features are limited, subject to change at any time and will more than likely have some instability. Only basic property types are currently supported i.e. no repeating value properties, there also isn't any support for categories, tags or associations.



Over the next few weeks I will try and write several 'How To' posts highlighting the features as they are implemented, in the meantime, please check out the source code from SVN, start investigating and provide us feedback.

Filter Blog

By date: By tag: