An Introduction to the SimpleDAM API Protocol

This feature article was written by DAM News editor, Ralph Windsor and published on 15th November 2022.

The Digital Asset Management software industry is a highly fragmented market.  There are at least 200 DAM vendors and some estimates place the true number in the thousands.  Although they all have digital assets as a consistent theme, there is little else which unites them and no common standard for exchanging data.

At the same time as an exponential growth in the number of platforms, there has been a corresponding increase in the range of specialist tools and add-ons which enhance the functionality of DAMs.  It is practically impossible for any DAM developer to not need to utilise one or more third party products now in order to compete with their peers.

This has created a significant issue for both DAM tool developers and vendors, alike.  In the case of the former, it means taking bets on which vendors are likely to provide them with the widest possible target market and/or developing a wide range of different connectors.  All of these require dedicated maintenance and if the vendor changes their API, the connector has to change also.  This adds a considerable overhead in terms of not only cost but also development staff time (and arguably the latter is a more serious issue).

The situation for DAM vendors is far from ideal also.  If there is particular tool they want to integrate with because customers have asked for it, they either need to persuade the tool provider to develop connectors and/or fund implementation of it themselves.

One option which a number of tool vendors take is to choose generic fie sharing platforms like Dropbox, Google Drive or Box.  This then requires DAM vendors for whom there is no custom connector to use the aforementioned products as de-facto intermediaries.  This places them at a further disadvantage, especially when they want to highlight the advantages of dedicated DAM solutions as compared with file sharing alternatives.

The fundamental issue at the heart of all this is the lack of any interoperability standards or protocols in DAM.  In terms of what prevents the industry achieving a greater level of enterprise penetration, this is possibly one of the biggest challenges (if not the largest).

Enter SimpleDAM

Standards and interoperability protocols have been talked about for decades in DAM.  Countless people have repeated the line about what an important development it would be for the long-term sustainability of the industry, but no one has actually done anything practical in terms of a protocol you can use.  Long-term DAM News readers will no doubt be aware that ‘the leadership’ of the DAM market tend to say very little about this topic.  Whether it is because they don’t care, don’t know (or possibly both) is a question that others can ask of them.

Having grown tired of waiting for the DAM market to do something about an issue which poses an existential threat to itself, we have decided to take matters into our own hands and have developed an API protocol called ‘SimpleDAM’.  This is a very basic REST-based API standard which defines some core common features which nearly all DAM systems offer.

To demonstrate that the protocol is credible, we have implemented a very simple API-First DAM application which uses it.  You can see this in-action here: https://simpledam.damnews.org/ user: mail@example.com, password: password

An administrator account is available also, to get access to that, you need to join the SimpleDAM Google Group: SimpleDAM – Google Groups – https://groups.google.com/u/2/g/simpledam

The documentation is here: https://simpledam.damnews.org/docs/

Licence

SimpleDAM has a three clause BSD open source licence which is one of the more permissive open source licences.  You don’t need to pay anything to start using it.

Implementation Details

The code for the application is available on Github: https://github.com/SimpleDAM

This is provided to give developers an example application and a test front-end.  Either your DAM (or your tool which connects with it) needs to be able to respond to REST-based calls and process JSON data.  The test application is written in PHP and uses jQuery, but providing you stick to the protocol and serve JSON back to clients, you are free to use whatever implementation technology you choose.

Simple DAM Compatibility Level

There are currently two levels of SimpleDAM Compatibility: 0 and 1.  To be SimpleDAM compliant, a minimum of level 0 is required.  Using the documentation page, you can filter out features above level 0.

Level 1 features are not necessary for the basics of getting assets into and out of a DAM.  For the most part, these exist to illustrate how SimpleDAM can be extended in the future without compromising the core input/output requirements.

Getting started

Having played around with the test application and seen what JSON data it returns, the easiest way to get started is to download the front-end source code and start to implement server-side handlers for processing the calls issued to it.  When your front-end is connected to your implementation of SimpleDAM, it should behave in a more or less identical way to the test application.

If you are a tool vendor, you can use the demo application to build a SimpleDAM connector which should work with any other DAM which follows the same protocol.  We have a testbed/sandbox where it is possible to issue SimpleDAM calls which developers might find useful also, this is https://github.com/SimpleDAM.

We fully expect problems and issues to come to light.  The place to discuss these is on the SimpleDAM Google Group, which we strongly encourage you to join.

Issues and Areas for Improvement

This is the first edition of SimpleDAM and, as such, there will almost inevitably be changes and improvements which need to be implemented.  There are three key areas where changes are expected:

• Authentication
• Metadata
• Collections/lightboxes & other advanced functionality

Authentication

The authentication method in SimpleDAM is too simplistic.  Issuing a username and password in the code to login is potentially insecure and will require an alternative approach.  There are many options, such as using API tokens or other protocols like oAuth.  We are going to take our cue from the DAM development community about which is the best route to take with this.  We have done the groundwork for SimpleDAM, but it is up to the DAM development community to define where it goes next.

Metadata

There is some very basic core metadata which SimpleDAM uses, but this is likely to be insufficient in many cases.  Attempting to define a standardised DAM metadata protocol which covers every single eventuality is something many have previously attempted, but with fairly limited success.  Our solution to this is simple.  We have a metadata node in the JSON data which is returned from get asset operations called ‘extension’.  Into this, each development team can include their own metadata packet unique to their DAM.  There is an example SimpleDAM extension to illustrate how this might work.  In some of the test assets you will also see extensions for EXIF.

The disadvantage is that there is no standardisation of the extended metadata which is returned from a given provider and this might mean whatever receives it has to uniquely process the metadata fields on a case-by-case basis.  The advantage is that it is at least handled in a consistent fashion so case-specific metadata is easier to deal with.  A further option would be to use one of the pre-existing metadata standards, e.g. Dublin Core, IPTC etc.

Metadata standards are currently outside the scope of SimpleDAM until/unless the community decides it wants to take on this task.

Collections/lightboxes & other advanced functionality

Astute readers will note that SimpleDAM has no capabilities to create custom collections of assets (aka ‘lightboxes’).  This might be a feature which gets added later, but at present, it would take SimpleDAM away from being very simple (and hence out of scope).    Whether this functionality gets added to SimpleDAM as a higher compatibility level in the future is up to the community to decide.

SimpleDAM FAQs

Below are a few questions which we anticipate will be asked (and the answers to them).

This API protocol is too simplistic, we have a far more advanced one which lots of our customers and partners have developed integrations using.  Why do we have to use this?

SimpleDAM is designed to be universally applicable across numerous DAMs so that tool developers and third parties do not need a custom connector for every single DAM in existence.  It does not need to be your only API.  It is both acceptable and expected that vendors will keep a ‘native’ API which they continue to use.  SimpleDAM is a secondary API which gives you compatibility with potentially lots of other third party tools – and other DAMs.  You can think of it as a generic utility connector with which you can integrate with third party tools.

We don’t use PHP and jQuery, we have much more up to date technologies, what about Python, Angular, NoSQL etc.?

SimpleDAM is only a protocol, you can use whatever you like to implement it.  In theory providing your product can respond to HTTP REST calls and send/receive JSON, you could implement it using Fortran and ISAM files if you really wanted to.  Practically every DAM that is still maintained and has some kind of API which uses REST these days.  That is the extent of the technical requirements to implement a SimpleDAM interface.

We don’t like the way the authentication and metadata works with SimpleDAM.  Why do we have to use it?

In which case, you need to get involved in the discussion group to help shape its development.  The direction the protocol takes in the future will be determined by the community.  See the points above about issues and areas for improvement.

We’re a tool vendor and SimpleDAM has almost none of the functionality in its API that we require, how can we use it?

It’s important to point out that SimpleDAM is designed to be implemented by DAM developers so their DAM can deliver assets to third party tools.  Tool vendors integrating with SimpleDAM should expect to receive asset JSON packets which are delivered in a standardised fashion.  Where DAMs integrate with third party applications, the expectation is that the DAM will still need to make custom calls to them using whatever protocol is preferred by that tool.

The scope of SimpleDAM is to make it as consistent as possible to get/set asset data from DAMs so integration is a lot easier.  The clue is in the title, SimpleDAM is DAM-centric, not tool-centric.

Summary of key links

Below are the links to the demonstration system, documentation, github repos and Google group.

SimpleDAM test application

https://simpledam.damnews.org/

user: mail@example.com

password: password

SimpleDAM Documentation

No login required for the following:

https://simpledam.damnews.org/docs/

You need to be logged in to use the API sandbox as it requires a session token:

https://simpledam.damnews.org/api-sandbox

SimpleDAM Github Repos

The front-end and back-end are provided as separate repos.  DAM Developers should be mainly interested in the front-end, which they will connect to their own back-end DAM.

https://github.com/SimpleDAM

SimpleDAM Google Group

SimpleDAM discussions can be conducted via the Google Group:

https://groups.google.com/u/2/g/simpledam

Share this Article: