They are all part of a new concept in Magento 2 called Service Contracts. 

Data models are intended to map entities, e.g. A customer, product, category. They should only contain properties used to describe those entities and methods used to set/get that data (mutator/accessor methods). They should not have any logic which define how the Data Model is saved/loaded however (that responsibility is handed to Repository Models) or any behavioural logic, e.g. Password reset methods (that is handled in the Management Interfaces).

A Repository Model defines common CRUD operations (Create, Replace, Update, Delete) for models. Though Repository interfaces do not extend from a common interface, they do share some common methods, e.g. `save`, `getById`, `getList` and `delete`, which are self-explanatory.

API models are better described as 'Management' Models. Logic which is relevant to an entity but which is not related to setting/getting data is encapsulated here. For example, for a customer entity, you would want to add some logic which handles passwords (e.g. Password validation, resetting passwords, etc). This logic goes in the Management model.

**Differences between Magento 1 and Magento 2**

To save an entity, the data model is passed to the save method of the repository. This is different to Magento 1, where the Data Model had it's own load/save methods which were used to load and save the entity.

Magento 1 collections do not exist in the same fashion in Magento 2. Instead, calling the `getList` method of a repository will return an array of Data Models. This array can be filtered by passing a `SearchCriteria` object to the `getList` method, which is analogous to calling `addFieldToFilter`, `AddAttributeToSelect`, etc methods on a collection object in Magento 1.

Under the hood, if you dig deep enough, you'll actually find that a lot of these Magento 1 ORM concepts are still present in Magento 2, which means the Service Contract layer is more of a wrapper for the old Magento 1 logic. This is because Magento 2 is basically a rewrite of Magento 1. Using the interface-driven approach of defining classes means that a lot of the refactored Magento 1 code can be hidden behind the shiny new Service Contract interfaces, whilst the core team (or community) refactors the underlying Magento 1 code (It is Magento's stated intention to get rid of all the refactored Magento 1 code eventually).

Source: https://devdocs.magento.com/guides/v2.2/extension-dev-guide/service-contracts/service-contracts.html