shelidonNovember 5, 20241 Comment on AEC Data Model API: an introduction

Autodesk announced lots of news during last October’s Autodesk University and, though some of them weren’t really new, we do have some interesting development, especially on the cloud services. You can find the full list here.

Since I am bound to forget to look into it or forget that I’ve looked into it altogether, I’ll try to do a series of posts looking into them, starting with the thing I understand less about the AEC Data Model API. I fortunately have people who understand them more than I do, but let’s see if I can wrap my head around the topic. Should this article contain any mistakes, please point them out. As I said, I’m no expert; I’m just trying to wrap my head around it. Hopefully this will be useful for other people like me, who are familiar more with the topic than the solution.

So, here we go.

The AEC Data Model API from Autodesk is aimed at helping AEC teams work more effectively with data within their Common Data Environment’s technological solutions of choice, mainly the Docs module in the Autodesk Construction Cloud, at least for now. Built to enable streamlined, cloud-based data management, this API leverages the GraphQL framework to access, retrieve, and manage data assets across projects. So what does that mean?

0. Some Basics

What’s an API?

It’s not an Active Pharmaceutical Ingredient, in case you’re wondering. It stands for Application Programming Interface and it’s basically a set of protocols, tools, and definitions that allows software applications to communicate with each other. It acts as a bridge, enabling one program to request and access data or services from another. For example, when an app needs to fetch weather data or process a payment, it uses an API to communicate with the relevant service. APIs are essential for creating efficient, modular software systems, as they allow developers to integrate third-party functionalities. That’s according to the definition provided by IBM, at least.

What’s GraphQL?

We’ll have to get deeper into it, but for now, let’s say that GraphQL is a query language for APIs that allows clients to request only the data they need, enhancing efficiency and flexibility in API interactions. This contrasts with traditional REST APIs, which typically return fixed data structures regardless of the client’s specific needs (see here for some differences). By enabling clients to specify the exact data fields they want in a single request, GraphQL improves data efficiency and reduces server load. This capability helps create more dynamic applications, particularly in complex environments where data requirements can vary significantly and addresses concerns such as the excessive consumption of data centres due to superfluous flux of data.

Expanding on that, we’re talking about the ability to prevent over-fetching and under-fetching of data. In REST, clients often need multiple requests to different endpoints to gather related data, leading to inefficiencies. In contrast, GraphQL allows clients to request all necessary data in one go, significantly reducing the number of requests made.

GraphQL also operates through a single endpoint, simplifying the API structure, and this is another difference from REST, which typically involves multiple endpoints corresponding to different resources. This single endpoint approach facilitates easier management and integration. Its ability to unify various systems behind a single API is particularly beneficial for organizations dealing with legacy infrastructure (which is that solution your previous boss bought thirty years ago before retiring and no one wants to shed because they’re still grieving his departure) or multiple microservices (which usually are your boss’s third cousin’s solution for a database, mildly integrated with that thing someone bought on eBay three years ago). It was developed by Facebook, I wonder why, and has gained widespread adoption due to its adaptability for complex applications, including those in AEC, and cloud-based environments. Other differences with REST are listed here.

1. What is the AEC Data Model API?

Autodesk notes in its Developer’s Guide, “The AEC Data Model API provides a programmatic way to access and manage a variety of AEC project data, including design files, parameters, and metadata.” This versatility in data access makes the API valuable to integrate workflows with Autodesk’s services.

Some benefits of the AEC Data Model API include:

• Unified data access across Autodesk’s AEC platforms
• Easy and flexible querying with GraphQL
• Access to a variety of data points, such as project metadata, design elements, and change tracking
• Support for custom data structures based on project needs

Compared with the previous strategy, as explained by Martyn Day in this article, the key difference is granularity.

Changing the fundamental technology on which your applications and customers have built businesses on is not for the faint hearted. Keeping desktop software sales alive, while re-engineering filebased workflows to ones that are granular is like changing a car tyre at 90 miles an hour. With the release of this AEC data model API, we now have some insight as to how Autodesk will engineer the data model component.

Think about your thousands of Revit models sitting in your Common Data Environment. Yeah, they’re intelligent and information-rich when you open them, but they’re dumb as a rock while they’re sitting there and, let’s face it, you’ll never open them.

2. Why GraphQL?

The AEC Data Model API uses GraphQL because of the qualities I illustrated before, mainly the capacity to request specific data elements rather than having to make multiple calls or parse through irrelevant data. And we all know how much irrelevant data is contained in a Revit model, don’t we?

GraphQL is well-suited for the complexities of these models, where users may want access to highly specific data points, like a particular component within a building. Autodesk’s documentation emphasizes that “GraphQL allows clients to precisely control the data they receive, reducing the need for multiple API calls.” For example, if a user wants to retrieve data on structural elements, the system can query only those elements directly, excluding unrelated elements, instead of querying the whole thing and then parsing out what wasn’t needed. This precision supports efficiency and reduces the load on both the API and the client-side application. At least that’s my understanding.

3. Core Use Cases of the AEC Data Model API

The AEC Data Model API is presented in relation to three key scenarios:

• Data Aggregation Across Projects: firms working on multiple projects can use the API to gather insights across their portfolio, comparing data such as project timelines, resources, and design consistency, or it can be a lifesaver when, as it often happens, you have your project spreads through different spaces on ACC (because Firm A doesn’t trust either the technology or Firm B and each one has their own space);
• Cross-Platform Data Sharing: If teams are working on different Autodesk solutions, they could use the API to share data seamlessly across applications, though I’ve yet to see a user case for this;
• Automated Reporting and Tracking: the APIs are integrated with the resident reporting tools on Autodesk Construction Cloud, and they can be connected with local reporting tools an AEC firm might have.

That’s at least according to the AEC API overview.

4. Enhanced Data Management for Revit (and Beyond)

One of the standout features of the AEC Data Model API is its compatibility with Revit. As we know, a Revit model usually holds vast amounts of data related to building elements, and the AEC Data Model API facilitates access to this data. It might be data on specific components like walls, windows, or beams, or a collection of these elements. As I’ve highlighted before, the AEC Data Model API enables users to pull this data selectively, allowing them to focus on the exact elements that are relevant to their task.

Additionally, beyond Revit, the API extends to other Autodesk products within the AEC ecosystem, such as The Software Formerly Known As BIM 360, making it a versatile tool for firms that work across different platforms and making it easier to transition from BIM360 to the new Autodesk Construction Cloud, an issue I’ve heard from many companies in San Diego.

If you’re the type of person who enjoys videos (which I’m not), you can hear more about it from her.

5. It’s all Cloud-Based

The AEC Data Model API is part of Autodesk’s broader push towards cloud-based solutions for the AEC industry, and I’m a big fan of that, don’t get me wrong. Cloud storage allows for real-time collaboration, with multiple users able to access and edit project data simultaneously, enables you to work from anywhere and provides built-in redundancies in ways you don’t have to worry (too much) about. It reduces the risk of data loss, as files are stored and backed up on Autodesk’s servers rather than on local drives, and if you think your servers are safer than the cloud, you’re really outdated, and there’s a bench somewhere for you to sit on.

This shift to the cloud aligns with the broader industry trend of digital transformation. I’m all for it. If, as I said before, we could find or at least look for a way for data centres not to kill us.

6. Getting Started

For those interested in exploring the AEC Data Model API, Autodesk provides a Developer’s Guide with detailed instructions on setup, authentication, and API usage. The guide covers everything from accessing the API through Autodesk’s portal to using example queries to retrieve data. To begin working with the API, users must first register for an Autodesk Platform Services (APS) account. This account provides the necessary credentials to authenticate API requests, ensuring secure data access. Autodesk also offers a range of tutorials and sample code on its developer page, helping users get familiar with basic operations.

Or you could stick around, and we’ll see some of the possible applications together.