Up and Running with Data Exchange API: Where Does Model Derivative Fit?

PRESENTER: Hi. So welcome to Autodesk University. This presentation is given to you by Jaime Rosales and Dennis Grieger. We both are part of developer advocacy and support and we are actually the persons responsible for writing blog posts, tutorials, samples, and things like that. On this slide, you can notice Jaime's Twitter account, and I highly, highly recommend to follow him, because he is very active in promoting interesting sample posts, events, and so forth.

Before proceeding, a necessary statement which in general warns you to not make any business decisions based on presentation, mainly because some of the things I'm about to present are still a work in progress. We are going to present some visions and plans, and that might change along the way, might change their name, the scope, and so.

Well, now that the so-called rule engagements are clear, let us see what is our agenda. And in this presentation, we will start with a very short review of the Data Exchange workflow, but from a user perspective.

Then, before jumping into kind of what that exchange has to offer to a developer, we will look over some concepts that exchange operates with in order to describe data, to organize data range, and things like that. We'll see the structure and try to understand why it is arranged as is, what are the benefits, and kind of works. And so forth.

Once we have all the concepts in place, we will look into developer tools. So what is offered to the developer as a tool in order to access to tap into data.

We'll have an overview. We'll look at the concepts with tools. And as a sort of a general conclusion, we will see when to use that exchange. What are the workflows where that exchange shines, and where actually you should avoid it, or let's say that there may be better options instead of using the Data Exchange.

And let's begin with the beginning. How about that? Before jumping into data exchange overview, let us have a very brief look of the problem that data exchange tries to solve in the very first place. And in many other previous presentation during the previous AU, we talked about challenges in cross application collaboration.

So you see you have this silo Revit, Inventor, or different many apps. The main vision is to move away from the binary files, and use the data layer as a sort of exchanging channel. And the Data Exchange service is not a solution, but rather a step forward towards this idea. And this is a way kind of breaking this barrier and starting to streamline the data.

Moreover, the Data Exchange here, it's not just another kind of Forge service and things like that. It's actually a key piece into a bigger picture. The cloud information model. I will not present here about the cloud information model. They have a specialized class for that but important to keep in mind is that data exchange or investing in data exchange is not investing only in just a Forge service.

It's investing time and effort in understanding it, will actually benefit you when you will work or start working with the cloud information model. OK, now that everything is kind of clear, why the Data Exchange is basically needed, let us look quickly through data exchange workflow from a user perspective.

For now that exchange, creation workflow is available only in context of ACC and only with Revit 2023 files. However, as we will see further, this is just the very first step in the future. The source app, as well as the environment will be extended.

The current implementation of the producer connector, we'll see later what it means by the producer connector, but it's a piece of that exchange that will take the source file and create the exchange out of it. So in this case, the producer connector now relies on the view. It requires a Revit view from which you will create a data exchange.

And you see, here we see that it will use 107 objects present in that view and extract all the data with the geometry properties and things like that. We can rename the exchange if we want. And once the exchange is created, since it also contains the 3D view, it can be visualized in an ACC viewer. And once it is created, we will see that actually it will contain all the information taken from a Revit view. Exactly kind of the same view.

And it will have the very same structure and the properties, and later we'll see that it has even more. And as you can see here, it has a zero size. So keep in mind that unlike a Revit file, which have a size, it's a file, the exchange item that was created here is not a downloadable item. This is mainly a point to the data that is actually exchanged.

And once we upload a new version of the Revit file or in this case, if the Revit file is updated, then it automatically triggers creation or updating of the exchange. It's not creating the new exchange. It will just update the exchange. So in this case, we updated that Revit file, and we see that we added a door.

And the building tool, the diff tool, that is available in ACC, allows us to visualize the difference between the two versions of the Revit file. And right here, we can see that the wall was modified. And a door was added, or let's say a door was added and the wall was modified. However, here we just visually see that something changed.

But what actually changed? What are the properties that changed for the wall? For sure, the volume, the surface changed, from which world value to which value. So we see, these kind of information is actually the answer by the Data Exchange. And we will see how to actually access this kind of information in the Data Exchange.

In the Data Exchange, the version 2 of it, will have exactly the same changes with properties modified and things like that. But we'll see later how actually we can access more than that.

In general, when we are talking about the Data Exchange workflow, we are illustrating Revit to inventor workflow. So the Revit is creating something, inventor is consuming. And this workflow is done through data exchange, but actually this is kind of one of the examples. And a new kid on the block is Revit Power Automate, where actually the exchange created from the Revit file are consuming Power Automate.

By the way, there is a class by my colleague Cesar Escalante which talks about exactly this thing. So how to take the exchange data from the Revit file using the Power Automate and put it in context of power BI, so we will end up having nice reports charts and everything else management usually like to have.

Anyway, so as I was mentioning, Revit to inventor, Revit to Power Automate, and things like that, this could actually be abstracted. And this is the purpose of the Data Exchange on the long term is to make an abstraction and to have the workflow application one produce a connector, cloud storage, consumer connector, and Application Tool or the target app.

And actually the key points here the producer connector and consumer connector because these will be the programmable points, and there is a special need for that because well let's say that grabbing the data from application one is not a big deal. Storing it in the cloud again, it's not a big deal. However, there are some challenges here. Let's say like number 42. Storing in cloud, a number 42 is not a big deal. But what is 42?

For one application, this could be the width of the window. For another application, well, this could be the meaning of the universe. So it's not enough to store the value. You have to actually store the meaning of this value along with the data. So what is this 42? Is it actually width of the door? Yes it's a width of the door. What kind of units is it using? Is it using feet, meters, or things like that.

So you see these kind of information is needed in order to have everything organized and at the same time to keep it consistent. Now 42 is a number. Tomorrow 42 is a string and it can break a lot of things. And this is why the producer connector and consumer connector are responsible for setting the data and also interpreting the data.

Moreover in this workflow, the application one, using the producer connector, can save a lot of data. However, the consumer connector can just cherry pick the data that it needs, and serve it to the target application. Moreover, if something changes, so application one changes some of the data, the consumer connector will be responsible of getting only the difference and kind of serving to the target application.

And we'll see later how actually this is done and moreover, the consistency of the data and how the data is organized and then [? Revit ?] is done through the schema service. And again, we will touch that along the way when we will talk about that exchange, assets, relationships, and things like that.

So as you can see, all the workforce share the very same pattern. The producer connector gets the data from source app, and the consumer connector kind of interprets the data and the serves and all is consistent. And actually what is kind of the key, or what will be available to developer are these kind of producer connector and consumer connector as a form of connector kit. But we will talk about that later. And we will see the plans and what is the state of this plan and so forth.

So before getting into like under hood and how the wheels are working and things like in data exchange, we have to master the Data Exchange concepts. So what are the concepts that are used in order to kind of operate with the data? How to structure, how to see the difference between the versions of the data, and so forth.

And they are not many. And actually out of these, we will see later that we would need only three of them. But these are the concepts that exchange operates with. So the very first one is collection. In context of ACC, a collection is actually the project. So what it means is that in context of ACC, when you are creating exchanges in this folder, in that folder, or different folders and things like that, but in the same project, they will be part of the same collection.

Therefore, looking plans about that again, just kind of a speculation, so you have different designs and all the designs are using the very same window. Having this environment, that all exchanges are in the very same collection, will make possible later to have something like give me all the designs that are using this window, and basically uses a filter criteria. Anyway, the space corresponds to an exchange container and represents a logical group of assets.

So all the data that you will expose in that exchange will be part of the very same space. So again, look it as a kind of exchange container. Assets, one of the most important here, the one responsible for holding properties, corresponding to a part or a group of parts of the model. Again, we will see in detail later. Relationships, of course, show the connection between assets.

And the last two are also very important, because they will be the key for accessing some states of all the data. So the snapshot is basically sort of like a pointer to the graph. All these assets are like nodes. Relationships are the edges, and they are forming a graph. And the snapshot is the pointer to that graph. But this graph from version to version will change. Some edges will sort of disappear. New assets will be created. New relationships will be formed, and things like that.

And snapshot will point to this prop, but the revision, the snapshot revision, the full name, will point to the different states of that graph. So you have graph one, something changed. You have graph two, something changed. You have graph three. So the revision will point to different versions of this graph. Again, we will see in detail later.

So again, the most common part is the asset. You'll be using it mostly, because it is one responsible for keeping the data. It contains the data. Whether there are multiple types of specialized assets, depending on their specialization, technically they are the very same. However based on their type of their specialization, they will contain a certain information or amount of data.

So let's start from the beginning geometry and binary and render style assets and things like that I used to store information related to graphics, visualization, and things like that. Later we will see that they will be usefully accessible through a special SDK that will allow you to extract the geometry. However, for purpose of accessing the data, we are interested in first three. Group asset, design asset, and instant asset.

The group asset are used in order to keep track of category, families, types, and things like that. So it's actually grouping the assets. It's an asset pointing to different other assets and those forming a sort of a group. A design asset is used in order to store common data. So imagine you have two doors. They share the common set of properties, so it will be sorting in design data. But each door also contains some individual properties specific only to those doors.

Then they will be kept in an instance asset. So when you want to basically aggregate the data, you will take the data common to all doors, plus specific to this door in the instance, aggregate, and this is the properties of that specific door. It is very useful for data deduplication. There is no point to repeat the very same data. And this is why design asset is used as a reference.

And all these kind of references, basically relationships, there are two types. The reference, the simple association between assets, and containment. So in the example, with the door, a doorknob part, and the door assembly. So you can see kind of the doorknob is contained in a door assembly. So there is a containment relationship between that. And relationships are the one that are connecting the edges or the assets, and they are forming the graph.

At this stage I can tell you, because I will be repeating it over and over, actually when we are saying something like a relationship or an asset was removed, it was not removed really. But it was just marked as removed. And why is that is because we have state of the graph one. Then we add some new assets and create some relationship, remove some relationship, and we have, say, two.

So when I am saying that remove some relationship is removed from this revision from this state of the graph, but they are not removed entirely from the graph itself. It's just for this state, they exist. In this state they are kind of marked as removed and this is why they are not taken into account. Again, we will return this to this later.

But the snapshot is basically the one that is responsible for keeping track of these different versions of the graph. And we will later see how actually the snapshot revisions are like marker in the time. Give me the state of the graph as it was for version one. Give me the state of the graph as it was for version two, and so forth.

And also the key elements in order to get the difference between two graphs. Give me all the assets and relationships that changed between version two and three, or two and five and so forth. We'll see you later.

The important thing is that we talked about collection, spaces, relationships, snapshots, and things like that. They all are actually entities, sharing more or less the very same structure. So ID is how to identify uniquely identify. Type is two distinct between the very same types.

Remember, we were discussing about the assets, at different types of assets. So we'd have design assets instance asset and things like that. Revision ID is the version of it. Again, we are adding a door to a wall. The wall will be like at least two assets. One with the revision corresponding to version one, and one corresponding to revision two. And this is how actually we can switch between.

Attributes contains the data, mostly system specific. We will see later again an example of that. And the components part of the entity is actually the most important, because this is where the data resides. And in case of assets and the relationship, the operation, insert, modify, and remove, marks actually what is the state of that asset. So if it's insert, it's a new asset. If it's modified means that asset was modified in a certain point.

And removed is again nothing is deleted is just marked as removed for a specific revision. And then, kind of based on specialization they can contain different fields. So in case of relationship it will contain from and to assets in order to show the direction of a relationship and in case of assets space, field will contain the ID in order to show that these assets belong to a certain space.

And this is conclude basically the concepts we will be retaining along the way. And using these concepts in order to describe certain parts and certain kind of elements of the Data Exchange and reference to them.

And knowing these concepts or understanding them at least kind of briefly will help in understanding the developer tools that will be available, or are already available, would work with that exchange because they will heavily rely on those concepts. Out of which, the most important are assets, relationship, snapshot revisions. Three concepts the most important. And we will reiterate that along the way, even in the demo.

So from a tool perspective, there are three tools here. That let's say not available, but more like present that will be available in perspective and things like that. The REST API is available right now as a beta.

And the most important thing being in beta, it means that it can be still shaped by you. So please try, please contribute, please complain, because this is the state where actually the API can change without any problems. Once it will be settled, the only way of changing it is just a new version, the next version. So now it's version one, but it's in beta, so you still have the power to shape it, contribute to it.

The REST API is actually the foundation. So what it will allow you is to access the row data, so you will access huge JSONs with assets, relationships, and a lot of data. The drawback of that is that it's a lot of data, and it might look into well a bit intimidating form what we'll see later when I will show you how actually the data is stored as a change sets.

GraphQL is sort of an attempt to solve this problem. So it will facilitate. It will give you a nice form, how to access it, and things like that. However, it's not so powerful as the REST API because it's basically a layer over the REST API, and this layer, as any layer, usually one designed they have the person who design them have their opinion, their vision how actually it should be and things like that.

So maybe someone who is heavily using GraphQL will look at this GraphQL implementation and say like, well I don't like because it doesn't have this, that, and that, and so forth. So you see again, when it will be available as a beta, you will have the power to shape it, to contribute how it will look.

And the last but not least is the connector kit, and remember we were discussing about the producer connector and consumer connector. It's actually will be part of the connector kit. It will facilitate accessing and searching the data, and we will see some examples of that. And the only drawback is that it's available only in C# or at least for now and only on Windows platform because it relies on some DLLs.

And I mark here as a partially available because technically, a part of the connector kit is already available as a beta. Again, if you hear beta, it should trigger something like OK I can contribute. I can criticize. So try it out and see if kind of suits you. But these parts, and I'm talking about the geometry utility as the game, we will see it later, is actually available as a separate piece later. It will be part of the connector kit.

OK, and let us start with the REST API because this is basically the foundation, and it's a very powerful hub. Yeah, you will see it lacks some things but still, it's very powerful tool.

If you look at the documentation for the Data Exchange here, REST API, you will see a lot of calls there, and they are more or less specific, the most important are these four calls. Get exchange container, get assets, get relationships, and get snapshot revisions. If you mastered this, you already kind of know the exchange and it's already kind of coverage from all perspectives.

I will try to do a demo regarding this and just to illustrate to you the workflow and how simple the Data Exchange API is. So remember when we were creating the exchange file, it resides in project files, and in Autodesk folder. Autodesk University folder. So technically before using the Data Exchange API, we have to know this item URN, or the item ID. And this is why, before proceeding to that exchange, we have to pass through data management API. And the data management API is pretty simple for those familiar with that. It's basically get the hubs.

In the hubs, you will get the one that you need. In this case, in my case, it will be like construction record testing, the projects, and get the projects. And here I'm interested in the project that I am. It will be the FDX testing [? products, ?] so I will require this ID for further enquiries, as you can see have ID, project ID.

I will go into the project files. I will go into project file contents. Here for sure I will find them. Autodesk University is one I'm interested in this ID, and when I'm looking at the folder's content, I can see those two files. This one is a Revit file and we can see in the [? extension ?] items, BIM 360 files. But the second file they exchange item. And you can see it's a BIM 360 FDX.

Again, remember it's not a file. It's not downloadable file. It's just a pointer, so what we need is this ID. ID of this item. Once we have the idea of this item, then we go into the Data Exchange world. And to get into that exchange world, we specify the ID, get the exchange, and we will get as you can see an entity which is a space with a lot of information.

As I was telling you, the attributes or contain system specific properties. They contain interesting data, but let us skip for now and look at the components. And the components contains also quite interesting data. So from Data Exchange, we have here three parts. This part, the source part, contains information about the source file.

So by source file means the Revit file. The Revit file was used as a source to create the exchange, and here you have the file URN, of the file project URN and what version was used in order to create the exchange.

The second part is the host, so it's actually the exchange item. And again, you have all the information about them. Where you ran, where it resides, the name, and things like that. And the third part is the contract. So in this context, and it will be very useful when it will be available to define your own contracts. There are plans about that for user defining their own contracts.

This is basically specifying what to get from the source file to create the exchange file. So what kind of data to get. And this is basically a template Revit view geometry, and being a template it's basically requires three things. And this template is basically saying, take this Revit file out of the Revit file, take this, view, and get all the data and kind of greater the exchange.

So one of the very, very powerful pieces will be when you will be able to define your own contract. This is the agreement. What kind of data I want to exchange? Because this one states not only what kind of data should be written but it could be used also as a consumer to see what kind of data is available.

Anyway, so from this exchange we are interested in two pieces. The ID of the exchange container, this is an exchange container, and the collection. Because all the subsequent calls will be done using these two parts. And remember I was telling you that this kind of exchange item is basically a pointer. It's not a file it's this item is a pointer to the graph.

But here we have only the tip, so there are two versions how actually to get the the version one or version two or things like that. So there is this goal, get snapshot provisions. And for each version, in the results will have its own snapshot revision. So the very first one and you can see the source version so with the Revit version one was used in order to create the version one of the exchange item. And the most interesting part here is actually about the stats so how many assets are created and how many relationships are created.

So remember, when we were creating the exchange item, I think it was something like 107 items. Well, those 107 items actually were distributed into 367 assets. So remember geometries, [? shaders, ?] design asset, group asset, and things like that. So it's quite interesting. Please don't be confused by these modified items, because when the graph is created, some items don't have enough data yet in order to be populated. So they are kind of created by default and then they are populated with data.

This is why it's set as modified, so they will create it and then modified with this data. And all these assets are connected through 655 relationships. A lot of them. Now let's go to the version two, and the version two is interesting because it shows us what items actually were created in version two.

Remember in version two, we actually added a door. And that door automatically will create a certain amount of assets, but also will modify some assets because the world was modified. So as you can see here, we have modified that items, created items, and again, nothing was deleted. Even if it saved removed, nothing was deleted. It is just marked that it's not part of this revision.

And when I say by the revision, the most important part of the revision is the revision ID, and why that is because when we will request the assets, all the relationships, the revision ID is a marker. So let's go to get the assets. If we don't specify any revision ID or things like that, this is basically asking the latest version. So what is the latest version of the graph.

However, if we specify as a filter, for instance, exchange snapshot to revision two, well in this case, it's useless because with it or without it we will get the latest because we have just two versions. But if we want to get all the assets and relationships as they were in the very first version, we just specify in the filter that we want the snapshot to revision one. So give me everything that was in revision one.

And the most interesting thing is, of course, difference between revisions. So we can specify from revision one to revision two, show me all the assets that kind of were created or modified or things like that. And technically if we will go here, we will get this number of assets. So it should be like 23 assets. 23 assets by having these filters, we will get back the 23 assets. Again,

We will look into details about the fields of those assets, but right now you already can see that an asset will provide you kind of, let's say not very convenient, the data will not be provided in a very convenient way for user in order to be consumed. And this is mainly because it relies on the schema.

So remember when I was telling you that the data have to be saved in the cloud in an organized way. And make sure that well in this case, if I want to save the host area computed, I want to make sure that this will be a float, not a string. And this is why how it's actually achieved through schema. And this schema technically can be visualized. If you go to a special path.

By the way, all the things that I'm showing here will be available in hand out for this class. So in this case, we can see the schema. So this is the total surface area, and it's measurable and part of the thing. So it's kind of description of the data, how it will be organized and things like that. And actually there is a neater way, but it's not documented. However, let me just kind of show to you.

There is a call, undocumented call, when I can say like give me all the properties that are used in this exchange, and this schema will be-- I think we can find this one. Yeah, will be presented in this nice way. So right here, we can see that this one will require a float value, area to the surface, it's a read only, and the storage unit is square meters, a very important thing.

So again, if we go here, to consume this data is quite difficult. You have to get this value, then you have to check the schema in which to make sure that kind of what the units are used and so forth. So it is quite clunky I may say, but why it is in this form it's not just to make life difficult. This form is called like a change set, and it's very helpful when there are a couple of values.

So in this case like, well if there are multiple values, especially mattresses, in case of the mattresses. And it allows you to save the changes between kind of versions. So what I mean by that is, imagine that you have something storing x and y-coordinates, and then you have a value for x. You have a value for y. And in order to change the y, you don't have to change the x or y.

And again, you just have to change the y by specifying the change set. So please modify y. And this way is actually how you specify that change. And it's very useful, because later you can cut consult this change set and see what changed between version one and three. Well, the y was modified two times from this value to that value from that value, and so on. So this format is very convenient for other work that is done internally.

And this is basically it. So as I told you the workflow is very simple. Having the item get the exchange, having the exchange get the ID of the exchange container and the collection, and they'll all the subsequent calls. [? Beat ?] get assets, [? beat ?] get relationships. We'll basically give you exactly-- we'll give you the data that you need.

So in this case, you can see I'm specifying the filter from revision one to revision I assume two. And I will get all the relationships that were kind of modified and the snapshot revisions. Here's the one that allows you to navigate between different versions of the graph, of different regions of the graph let us say.

And so you can see this is for the API. Again, as a review, snapshot revisions and diffs are, it could be in wanted to get the difference between different revisions, you have to get the snapshot revision. And here you have the important pieces.

This is the example that I told you about, the difference between version one and version two. So I see. In version one, since it's created from the scratch, you have a lot of assets created. You have a lot of relationships created. And these ones you see it's a modification, obviously, you have a smaller number. And having the revisions, you can get the assets. You can get relationships.

If you are not specifying the revisions, then automatically you will get the latest. If you are specifying the revisions, then it's basically, you can kind of play with it. So you can get a certain version. You can get the difference. And so forth.

As I told you, the data is kept in a not very convenient way. So we're seeing as an example here, we have area. We have land volume, and this is how actually it is reflected within the assets. However, look at the accuracy of the values. So here you have a float64, a very good accuracy.

In case kind of dimensions, I assume that a lot of that were approximated. And by the way, later we'll see how actually there is a way of changing the units from meters to feet and things like that. In version two, again it's reflected the change. And notice the difference between revision in the version one and version two is the revision ID changed. So an asset has its own ID, but also holds another field of revision ID, showing you to which revision it belongs to.

So if we look at side by side, revision ID for version one. Revision ID for version two. And they will be exactly the same as when you are looking at revision snapshots at the versions. They will be the very same, and technically, all the assets belong to a certain revision will have the same revision ID.

And this is how basically you are filtering from, give me all the assets or relationships that were in version one. Give me version two, and things like that.

As we mentioned before, in visually we could see that the door was added. That the walls was changed, and things like that. But the Data Exchange allows us to identify the assets that were moved, were created, and especially modified. And we can basically filter for those modified, and see how the data changed.

And any time when we adding something to a read file, a new version is created, the graph itself changes. New relationships are created. So here you can see left side, how it was in version one. By adding a door, how a our new version was created, and things like that.

So all of this allows you to exploit that. And actually let me do a short demo, How all this API is used in order to create kind of to extract the data. So this part is very kind of familiar for those that followed the Learn Forge tutorial. As we can see here, the Derivative file. We have the two versions of it, and we have the two versions of the exchange item.

But again, keep in mind that this is more for references. If you want to access different versions, they will be available only through revisions. Yes, visually, they will change the viewable, but the data under the hood, between version one and version two is accessible only through data exchange and snapshot revisions.

And here we have a small sample, just kind of showing you the information about exchange ID collection, exchange volume, and source Revit file, Revit view, and source Revit file. So this is all done through use of the Data Exchange API. When it's actually a get exchange call. And the exchange stats here, again, these are extensions written by me using the API. They are available as samples and basically give you some stats about the total assets relationships and based on different categories.

If we're interested in data, we actually have to look only at these types of assets, group design instance, the geometry renders style binary. Well, actually, the geometry is available through, as again we will see that later. In the relationships, type of relationship, and here is a convenient button to just download assets from relationship as a whole JSON and things like that.

So the drawback, and we will see later that there is a drawback for the REST API, at least for now, because this, it is still kind of in progress. So the drawback of the API is that it lacks filtering options. So right now, they [? get ?] straightforward, get the exchange container, get snapshot revision, get assets, get relationships, and so forth.

But it lacks filtering. So for instance, I want assets only of a certain type, or with a certain properties, or things like that. So the filtering is not yet in place. And this is why now the workflow is the following. Get all the assets, get all the relationships, and process them on the client side. So it means that you grab everything and process on your side. Filter as you like.

And this is one of the reasons why the GraphQL kind of come into place, because it will allow filtering. And another thing that is important is kind of the data is difficult to work with, because as you've seen, the structure is somehow difficult. And again GraphQL will try to simplify that. And again, we will see in a minute how.

So in GraphQL as I said, it's easy to get all the data as you need. And we'll see in a minute how, but again, you will get the data in the form and only the data as the engineering team thinks that you would need. And this is why it will be very important again, reiterate that, when beta will be available. Try it, feedback, shape it, and contribute to it. Because this is how the engineering team now sees how to access the data.

And actually the GraphQL is quite again even simpler. And you will have two entry points. Get exchange buy ID or get exchange assets. And let me do a very, very short demo on how the GraphQL is actually used. And for that I will be using another tool, a very nice one, that it's called Voyager. That actually shows you visually how the API looks, so the GraphQL API looks.

And the entry point, as you can see here. Let's take the very first one, is get exchange by ID. This is a call that will require exchange container ID. And what it will provide is basically this kind of information. But you can specify that I don't need that. I need just this, that, and that, and that. So it's basically, when we are trying to do this.

Let's say that we want to delete this one. OK, and we want just the ID so it means that give me the exchange by ID, but provide me only the ID. It's not very useful. Let's say, OK, I'm interested also in type. OK. So then, I will be provided also the type. Also not very important. So remember from exchange, we actually need collection ID.

So this is the collection ID. So it's a string, so OK. So I need a collection, and from collection I need the ID. So this is the form that it will be-- OK is expired. Well, let me refresh the token quickly.

OK. So this is the way how actually the it will give you the information. Technically, when you are doing the query, you specify what kind of fields you need, so it will not overwhelm you with a lot of data as it was in the case of REST API. The REST API say like, I want assets, and it will bombard you with the data.

But if you are interested only on certain parts of the data, then well, good luck. Filter by yourself. GraphQL tries to solve that. So in this case, for instance, I'm interested in attributes, and in attributes, I need only the data. And in data, I'm interested, so I'm going to this data attribute. I'm interested in name and value.

So name and value. OK. So name and then the value. So I will get only these fields, because this is what I requested. It will be only the name and the value. So remember, when we were looking at the Get exchange, we were getting in attributes a lot of things here, like name, value, type, category, and things like that. And category everywhere in this case is a system. So technically it's redundant and not interested. I am interested only in name and value.

So this is basically how GraphQL works, and as I was telling you, in GraphQL you will have certain kind of entry points. And the most useful now is the exchange assets, because it will give you the information about asset. And that information about asset will contain type ID operation and properties. And in properties you will have a lot of parameters, ID, descriptions, values, and things like that.

So let us look quickly how it will look. So here, this is how actually I can structure a query. You should not be scared, because this is like a consistent. It's information about the container collection, remember, in the REST API, when we were doing specifying Exchange container [INAUDIBLE] collection, and in GraphQL this is done through kind of this sort of parameters.

This one is used for auto pagination and what we are interested in value, properties. And in properties we are specified that we're interested in family, name, category, type. We can delete or remove and things like that. And in parameters, we are interested in ID, name, and things like that. So let us quickly run the query. And we can see right away here that we will be receiving interesting data.

So in this case, we have family, compound ceiling, name, this is basically ID. Ceiling, type, parameters, and it has a lot of parameters. And as you can see here, the parameters are specified. Meters, square meters, and things like that. And the good thing also along the way that you can remove, remember I was telling you that if we're not interested in these kind of things, we will not consume them. We can remove. They will not be present here.

But the good thing here is that we can actually specify also some fields. A very interesting field is the unit conversion. So in this case, I'm interested not in meters. I'm interested in feet. So in this case, if I'm specifying with this thing, we will see that actually the units were converted to the feet. The value also. So it means that it will do the value conversion, not only just to change the name to feet.