It is important to be familiar with a few key concepts to understand network automation. As you make your way through the network automation journey, you will be exposed to a whole new alphabet soup of acronyms and concepts. You should be familiar with a few important concepts in network automation, and model-driven programmability is one. This topic will explain what model-driven programmability is and how it has given rise to the growth of automation that we have seen in recent years. You may be exposed to some new concepts and technologies in this topic, but do not worry if you get a little overwhelmed; the key here is to become familiar with model-driven programmability.
了解網路自動化，需要先熟悉幾個關鍵概念。在邁向網路自動化的過程中，你會接觸到全新一整套的縮寫與概念。你應熟悉網路自動化中幾個重要概念，模型驅動可程式化（model-driven programmability）便是其一。本主題將說明什麼是模型驅動可程式化，以及它如何促成近年來我們所見的自動化蓬勃發展。在本主題中，你可能會接觸到一些新概念與新技術，但即使感到有些吃力也不用擔心，重點在於熟悉模型驅動可程式化的概念。
First, some background for perspective on the importance of model-driven programmability.The traditional CLI-based interface with its unstructured output and text-based commands is insufficient for automation. When networking devices first started supporting APIs, these were RPC-style APIs, taking and executing CLI commands. These kinds of APIs were not programming-friendly. It was not easy to extract information from unstructured text originally designed for humans to read. This led to the development of custom device APIs. However, these custom APIs did not regularly support full functionality and differed from CLI, which requires additional work to translate commands. Instead, a model-based approach to APIs can be used to address these and other challenges.
首先，先了解一些背景，以理解模型驅動可程式化的重要性。傳統以 CLI 為基礎的介面，其輸出未結構化且採用文字指令，不足以支援自動化。網路裝置最初開始支援 API 時，這些是 RPC 風格的 API，接收並執行 CLI 指令。這類 API 對程式設計並不友善，因為要從原本為人類閱讀而設計的非結構化文字中擷取資訊並不容易。這促成了自訂裝置 API 的發展。然而，這些自訂 API 通常無法穩定支援完整功能，且與 CLI 有所差異，需要額外的工作來轉譯指令。取而代之的是，可以採用以模型為基礎的 API 方式來因應這些挑戰。
A data model is like a standardized framework used to describe a data object of an environment. The thought behind the data model is to provide a consistent and reliable format to communicate the data objects you are working with on your device.
資料模型就像是一套標準化框架，用來描述環境中的資料物件。資料模型的核心概念，是為你在裝置上處理的資料物件，提供一致且可靠的溝通格式。
One misconception is that data models handle the exchange of data, which is not the case. Data models are just standardized frameworks that describe your environment. Data models have nothing to do with data transmission. Instead, protocols such as Network Configuration Protocol (NETCONF) and RESTCONF send structured data (e.g., XML or JSON) encoded documents using a framework a given model governs.
有一個常見的誤解，認為資料模型負責處理資料的交換，但事實並非如此。資料模型只是描述環境的標準化框架，與資料傳輸無關。實際上，是像網路設定協定（Network Configuration Protocol，NETCONF）與 RESTCONF 這類協定，依循特定模型所規範的框架，傳送結構化資料（例如 XML 或 JSON）編碼的文件。
Now that you understand a little more about model-driven programmability, it can be taken a step further and discuss how model-driven programmability fits into the larger concepts of APIs and network programmability.
既然你已對模型驅動可程式化有了更多了解，接下來可以更進一步，探討模型驅動可程式化如何融入 API 與網路可程式化的更大架構之中。
Now that you have an idea of what a data model is and the role model-driven programmability plays in API architecture, then this would be a good time to take the 50,000-foot overview of model-driven programmability's role in network automation. Consider the following figure:
既然你已了解什麼是資料模型，以及模型驅動可程式化在 API 架構中所扮演的角色，現在正好可以從宏觀角度，概覽模型驅動可程式化在網路自動化中所扮演的角色。請參考下圖：
Applications can now use programming libraries or development kits that leverage data models to simplify access to the API. Behind the scenes, different protocols using various encodings and transports may be used to exchange data but the application does not need to concern itself with that. It only needs to operate on the data models. Likewise, the API server uses the same model, regardless of the protocol, allowing the server to support as many protocols as required.
應用程式現在可以使用運用資料模型的程式庫或開發套件，來簡化對 API 的存取。在幕後，可能會使用不同的協定搭配各種編碼與傳輸方式來交換資料，但應用程式不需要關心這些細節，只需要處理資料模型即可。同樣地，無論使用何種協定，API 伺服器都採用相同的模型，讓伺服器能夠支援所需的多種協定。
Imagine that an application has requested to retrieve an IP address on an interface of a network device. The data request is structured according to the application's YANG data model. The application then sends a request to the API server on the network device. The network device can identify what data the request asks and constructs a response for the application. The response is formatted in an expected structure or model that the application is expecting based on YANG. For example, if the request were for an IP address on an interface, it would use the proper data model for interface IP addresses. The network device sends the response back and is received by the application. The data structure is in a format that the application expects since both sides are using the YANG data model. The figure demonstrates the role of data models in network automation in action.
設想一個應用程式請求擷取某網路裝置某介面上的 IP 位址。該資料請求會依照應用程式所使用的 YANG 資料模型加以結構化。接著，應用程式會將請求傳送給該網路裝置上的 API 伺服器。該網路裝置能夠識別請求所要求的資料，並為應用程式建構回應。回應會以應用程式基於 YANG 所預期的結構或模型格式呈現。舉例來說，若請求的是某介面上的 IP 位址，就會使用介面 IP 位址適用的資料模型。網路裝置會將回應傳回，並由應用程式接收。由於雙方都使用 YANG 資料模型，資料結構會符合應用程式所預期的格式。下圖示範了資料模型在網路自動化中實際運作的角色。
The two main data encoding formats commonly used are XML and JSON. Each provides a structured way of data formatting to send data between two computer systems. Since data conforms to the model, it is easier to navigate and extract relevant information programmatically. This is in stark contrast to using Secure Shell (SSH) issuing CLI commands in which data is sent as raw strings (text).
常用的兩種主要資料編碼格式是 XML 與 JSON。兩者皆提供一種結構化的方式，用於在兩個電腦系統之間傳送資料格式化的內容。由於資料符合模型規範，因此更容易以程式化方式瀏覽並擷取相關資訊。這與透過安全殼層（Secure Shell，SSH）發送 CLI 指令、以原始字串（文字）方式傳送資料的做法形成鮮明對比。
Sometimes the concept of data models gets confused with data encoding formats like XML and JSON. The data encoding formats are involved with the serialization format of how the data is transmitted. More simply stated, XML and JSON are not about the framework of how your model is presented but the way the data is formatted for transport.
有時候，資料模型的概念會與 XML、JSON 等資料編碼格式混淆。資料編碼格式涉及的是資料傳輸時的序列化格式。更簡單地說，XML 與 JSON 並非關於你的模型如何呈現的框架，而是關於資料在傳輸時如何格式化。
XML and JSON are used for data transmission because they have these features:
XML 與 JSON 之所以被用於資料傳輸，是因為它們具備以下特性：
- Human readable because they are self-describing人類可讀，因為它們具有自我描述性
- Hierarchical, because they store values within values階層式，因為它們在值中儲存值
- Parsable and used by many programming languages可剖析，並被許多程式語言使用
As we finish up , it is worth mentioning YANG , which is a data modeling language that you will likely encounter on your network automation journey. There are whole courses and even books just dedicated to YANG, but for now, it is important to understand that YANG is a data modeling language that is used by protocols like NETCONF, RESTCONF, and gRPC. The YANG data modeling language was published in October 2010 as RFC 6020 to serve as a data modeling language for the protocol NETCONF. So to finally put it all together, the image below illustrates the YANG model-driven programmability stack.
在結束本主題之前，值得一提的是 YANG，這是你在網路自動化旅程中很可能會遇到的一種資料建模語言。關於 YANG 甚至有整套課程與專書，但目前你只需理解，YANG 是一種資料建模語言，供 NETCONF、RESTCONF、gRPC 等協定使用。YANG 資料建模語言於 2010 年 10 月以 RFC 6020 發布，作為 NETCONF 協定的資料建模語言。最後，為將這一切整合起來，下圖說明了 YANG 模型驅動可程式化堆疊。
As you can see, data models are not really new but are getting more attention as a building block of the model-driven APIs.
如你所見，資料模型其實並非全新概念，但作為模型驅動 API 的基礎元件，正逐漸受到更多關注。