最近在學習CoAP協議，網上相關資料很少，於是自己各種翻RFC文檔。看這篇比較短，乾脆直接幾乎整篇翻譯下來給大家參考。後面再出個CoAP學習的筆記。
Last updated 2015-10-14
RFC文檔網上都是公開的，應該沒有版權問題，如有請聯繫我刪除。僅供學習交流使用，請勿用於商業用途。
受限RESTful環境(CoRE)鏈接格式
摘要
這篇規範使用一個鏈接(link)格式定義了Web Linking，給條件受限的Web服務器用於描述擁有的資源、它們的屬性以及鏈接間的其他關係。基於RFC5988中定義的HTTP Link頭部字段，受限RESTful環境(CoRE)鏈接格式被攜帶在payload中，並被賦值了一個因特網媒體類型。“RESTful”指的是表徵狀態轉移(REST)架構。一個知名URI被定義爲默認入口點，用於請求服務器擁有的鏈接。
1 介紹
受限RESTful環境(CoRE)以適合於最受限節點(例如帶有有限內存的8位微控制器)和網絡(例如6LoWPANs)的格式，實現了表徵狀態轉移架構[REST]。CoRE致力於 Machine-to-Machine(M2M) 應用，例如智能能源和樓宇自動化。
在沒有人工協助並且靜態接口很不好用的M2M應用中，能發現受限服務器擁有的資源是十分重要的。我們把HTTP web服務器所提供資源的發現[RFC2616]稱作“Web發現(discovery)”，把資源間關係的描述[RFC5988]稱作“Web Linking”。在當前的規範中，我們把發現 受限web服務器擁有的資源、它們的屬性以及其他資源關係 稱爲CoRE資源發現(CoRE Resource Discovery)。
這樣一個發現機制的主要功能是爲服務器擁有的資源提供通用資源標識符(URI，也稱爲鏈接)，加上相關的屬性以及可能有的進一步鏈接關係。在CoRE中，這個鏈接集合自身就是一個資源(不同於HTTP頭部中攜帶特定資源的那種方式)。這篇文檔指定了用於CoRE資源發現的鏈接格式，通過擴展HTTP Link頭部格式[RFC5988]來闡述這些鏈接描述。CoRE鏈接格式被攜帶在payload中，並被賦值了一個因特網媒體類型。衆知相對URI“/.well-known/core”被定義爲CoRE資源發現的默認入口點，用於請求服務器擁有的資源的鏈接列表。這篇規範可用於受限應用協議(CoAP)、HTTP或任何其他合適的web傳輸協議。這鏈接格式也可以被存儲爲文件格式。
1.1 CoRE中的Web Linking
技術上，CoRE鏈接格式是[RFC5988]中指定的typed link的一個序列化，其用於描述資源間的關係，所以被叫做“Web Linking”。在這篇規範中，用特定的受限M2M屬性對Web Linking進行了擴展；鏈接不是放在HTTP Link頭部字段中，而是被作爲消息payload攜帶，還定義了一個默認接口來發現服務器擁有的資源。這篇規範還定義了一個新的關係類型“hosts”(來自動詞“to host”)，它指明資源爲哪個服務器擁有，鏈接文檔就是從哪個服務器上請求來的。
在HTTP中，Link頭部可以用於與一個HTTP答覆一同攜帶資源的鏈接信息。這個方式在web服務器和瀏覽器下工作的很好，這個用例中，在獲取一個特定資源後，它的進一步信息十分有用。在CoRE中，Web鏈接的主要用法是在最開始的地方發現一個主機擁有的資源。儘管一些資源可能有進一步關聯的鏈接，那應該只是個例外。因此，CoRE鏈接格式序列化被作爲一個衆知URI的資源陳述(representation)。CoRE鏈接格式重用了定義在[RFC5988]中的HTTP Link頭部序列化格式。
1.2 用例
在當今web世界中，Web Linking的典型用法包括：描述一個網頁的作者或者描述網頁間的關係(如下一章、前一章)。Web Linking也可以用於M2M應用，在M2M應用中，typed links被用來協助一個機器客戶端去找到和理解怎麼使用一個服務器上的資源。在這個章節中，我們提供了一些用例來描述CoRE鏈接格式可以怎麼用於M2M應用。想要更多技術示例的話，見第5章。有大量的M2M應用，我們特意選了些常見的。這篇規範假設不同的部署和應用領域會以合適的資源類型來定義合適的REST接口描述，這樣資源發現纔有意義。
1.2.1 發現
在M2M應用中，例如家居或樓宇自動化，需要本地客戶端和服務器在沒有人工干涉的情況下相互發現和交互。在這種環境下，CoRE鏈接格式可以被服務器用於支持發現服務器上的資源。
資源發現可以用單播或多播來完成。當服務器的IP地址已知，不管是預知的還是通過DNS[RFC1034]解析出來的，我們會使用單播發現以定位入口點爲想要的資源。在這篇規範中，這是通過GET服務器上的“/.well-known/core”來實現的，這會返回一個CoRE鏈接格式的payload。客戶端隨後會匹配自己應用需要的資源類型、接口描述和可能的媒體類型[RFC2045]。可能還會再請求字符串中包含一些屬性以過濾答覆中返回的鏈接的數量。
當一個客戶端需要在有限的範圍中定位資源，且這域支持IP多播時，多播資源發現十分有用。一個GET請求會在合適的多播地址上請求“/.well-known/core”。爲了限制答覆的數量和大小，推薦使用帶有已知屬性的請求字符串。典型地，會基於資源類型 和/或 接口描述 以及 可能的應用特定屬性來發現資源。
1.2.2 資源集合
M2M接口的RESTful設計經常會使用資源集合(collections)。比如，數據匯聚節點中溫度傳感器索引或者家庭安全控制器的警報器列表。CoRE鏈接格式可以用來發現集合的入口點並訪問到它的成員。集合的入口點總是包含在“/.well-known/core”中以使它能被發現。集合的成員可以通過帶有集合大小參數的資源接口描述或者通過使用鏈接格式描述集合中的每個資源來定義。這些鏈接可以位於“/.well-known/core”，或者放在集合的根資源下。
1.2.3 資源目錄
在許多部署常見下，比如受限網絡下的休眠服務器或者帶寬受限網絡下大型M2M部署，部署資源目錄實體是有意義的，資源目錄上存儲着存於其他服務器上的資源的鏈接。可以把它想象成一個用於受限M2M資源的受限搜索引擎。
CoRE鏈接格式可被服務器用於註冊資源到一個資源目錄上，或者用於使資源目錄能輪詢資源。資源註冊可以通過讓每個服務器POST它們的資源到資源目錄的“/.well-known/core”上來實現。這會添加鏈接到資源目錄合適的資源下。然後這些鏈接可以被任何客戶端發現，客戶端會發送請求到資源目錄的查詢接口。
1.3 術語
這篇規範中的關鍵詞"MUST(必須)", “MUST NOT(絕不能)”, “REQUIRED(要求)”, “SHALL(應當)”, “SHALL NOT(不應當)”, “SHOULD(應該)”, “SHOULD NOT(不應該)”, “RECOMMENDED(推薦)”, “MAY(也許會)”, 和"OPTIONAL(可選)"應該按照[RFC2119]中描述的那樣解釋。
這篇規範使用了擴展的巴科斯範式(Augmented Backus-Naur Form (ABNF))[RFC5234]表示法，核心規則定義在文檔的附件B中。
這篇規範要求讀者熟悉[RFC5988]和[RFC6454]中所談論的所有術語和概念，這篇規範使用以下術語：
Web Linking
一個框架，用於指明web資源間的關係。
鏈接(Link)
在[RFC5988]中也被叫做“typed links”。一個鏈接就是兩個由URI標識的資源間的一個有類型的連接，包含一個context URI、一個鏈接關係類型、一個目標URI和可選的目標屬性。
鏈接格式(Link Format)
typed links的一個特別的序列化。
CoRE鏈接格式
typed links的一個特別的序列化，其基於定義在[RFC5988]第五章中的HTTP Link頭部字段序列化，但被攜帶爲有媒體類型的一個資源陳述。
屬性(Attribute)
更準確的說應該是[RFC5988]中的“目標屬性”。一個描述鏈接或者它的目標的鍵值對。
CoRE資源發現
就是當一個客戶端通過訪問"/.well-known/core"來發現服務器擁有的資源列表，它們的屬性以及其他鏈接關係。
2 鏈接格式
CoRE鏈接格式擴展了[RFC5988]中指定的HTTP Link頭部字段。它不要求特別的XML或者二進制轉換，相當緊湊，並且可擴展 – 這是CoRE的所有重要特性。要注意的是，這個鏈接格式只是定義在[RFC5988]中的typed links的一個序列化；其他序列化包括HTML links、Atom feed links [RFC4287]、HTTP Link頭部字段。我們期望CoRE鏈接格式中發現的資源也能夠以多種格式在更大的因特網上獲得。CoRE鏈接格式僅僅應該用於受限網絡和M2M系統。
[RFC5988]的第五章不要求定義的鏈接格式有一個因特網媒體類型，因爲它被定義爲攜帶在HTTP頭部中。因此這篇規範將CoRE鏈接格式(見章節7.3)的因特網媒體類型定義爲“application/link-format”。儘管HTTP Link頭部字段的編碼依賴於[RFC2616]，CoRE鏈接格式被編碼爲UTF-8[RFC3629]。CoRE鏈接格式的解碼器並不需要理解UTF-8編碼(當然能理解更好)，並且不需要做UTF-8歸一化。UTF-8數據可以按位比較，這使得在值中包含UTF-8數據不會導致受限節點增加任何複雜性。
CoRE鏈接格式等價於[RFC5988]鏈接格式；然而，當前規範重新給出了ABNF並進行了修改以兼容[RFC5234]幷包含了新的鏈接參數。這篇規範中保留了鏈接參數“href”用作過濾請求參數(見4.1)，其決不能被定義爲鏈接參數。如[RFC5988]中所述，多個鏈接參數由逗號分隔。注意，逗號也可以出現在引號包起來的字符串以及URI中，出現在這種地方不會終止一個描述。爲了轉換HTTP Link頭部字段爲這個格式，首先，移除“Link:” HTTP頭部，移除所有空行，將頭部的值轉換爲UTF-8，然後解碼所有的百分號編碼。
2.1 目標和上下文URI
每個鏈接都把一個目標URI表達爲一個包含在中括號("<>")中的URI引用。一個鏈接的上下文URI(在[RFC3986]中也叫作基礎URI)由這篇規範中的以下規則定義：
- 當指定anchor參數時，上下文URI就是它。
- 當指定時，是目標URI的源。
- 鏈接格式資源的基礎URI的源。
2.2 鏈接關係
由於CoRE鏈接格式中的鏈接典型地用於描述服務器上擁有的資源，新的關係類型“hosts”是用於缺失關係參數時(見7.2)。“hosts”關係類型(來自動詞“to host”)指明目標URI是一個被服務器擁有的資源(即服務器擁有資源)，由上下文URI表明。目標URI必須是這個關係類型的上下文URI的一個相對URI。
爲了表達其他關係，鏈接可以使用任何註冊的關係，這通過包含關係參數實現。一個關係的上下文可以使用錨參數定義。用這種方法，就可以表達一個服務器上的資源間或者服務器上資源與外部資源間的關係。
2.3 使用錨
根據[RFC5988]的章節5.2，一個鏈接描述也許包含一個“anchor”參數，如有，則上下文就是這屬性中包含的URI。這用於描述兩個資源間的關係。但是實現也可以選擇忽視這樣的鏈接。我們並不指望所有的實現都能夠從顯式的錨鏈接中提取有用信息。
3 CoRE鏈接屬性
一下CoRE專用的目標屬性是定義來補充那些已經定義在[RFC5988]中的。這些屬性描述了那些在訪問有關係的目標鏈接時很有用的信息，有些情況下可以使用URI的語義形式。·這樣一個URI也許會被解引用(例如，爲了獲得鏈接關係的描述)，但是這不是協議的一部分，絕不能在鏈接評估時自動完成。當比較屬性的值的時候，必須作爲字符串來比較。
3.1 資源類型屬性 — ‘rt’
資源類型屬性‘rt’是一個含糊的字符串，用於給一個資源賦值應用專用的語義類型。你可以把它當做一個描述資源的名詞。在資源是溫度的情景下，它可以是，例如一個應用專用的語義類型如“outdoor-temperature”，或者一個引用本體論中特定概念的URI，如“http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature”。這個溫度的值內也許會包含多種資源類型，使用空格分隔，類似於關係屬性。資源類型值的註冊在章節7.4中定義。
資源類型屬性並不是要你給資源賦予一個人類可讀的名字。[RFC5988]中定義的“title”屬性纔是幹這個用的。資源類型屬性絕不能在一個鏈接中出現超過一次。
3.2 接口描述屬性 — ‘if’
接口描述屬性‘if’是一個含糊的字符串，用於提供一個名字或URI以指定一個用於與目標資源交互的專用接口定義。你可以將其視爲資源上可用的描述性動詞。接口描述屬性是要用來描述通用REST接口以與一個資源或資源集合進行交互的。希望接口描述能被不同的資源類型重用。比如，資源類型“outdoor-temperature”、“dew-point”和"rel-humidity"都可以使用接口描述"http://www.example.org/myapp.wadl#sensor"來訪問。這個參數的值也許會包含多個接口描述，使用空格分隔，類似於關係屬性。資源類型值的註冊在章節7.4中定義。
接口描述可以是比如一個web應用描述語言[WADL]的定義，目標資源“http://www.example.org/myapp.wadl#sensor”，一個URN指定資源的接口類型爲“urn:myapp:sensor”或者一個應用專用的名字“sensor”。接口描述屬性絕不能在一個鏈接中出現超過一次。
3.3 最大尺寸估計屬性 — ‘sz’
最大尺寸估計屬性‘sz’標示了當往目標URI上使用GET時返回的資源陳述的最大大小。對於到CoAP資源的鏈接，這個屬性並不期望被用於可以直接舒服地放入單個最大傳輸單元(MTU)中的小資源，但是應該用於大小大於MTU的資源。最大尺寸估計屬性絕不能在一個鏈接中出現超過一次。
注意，‘sz’屬性的值沒有定義上限。實現必須準備好接受大的值。一個實現策略是轉換任何大於合理大小的值爲一個特別的值“Big”，然後在後續處理中就會發現值實在太大了，無法處理。
4 衆知接口
CoRE中的資源發現是通過使用一個衆知資源URI來實現的，它會返回一個關於服務器擁有的資源和其他鏈接關係的鏈接列表。如[RFC5785]中指定的，衆知資源有一個以“/.well-known/”開始的路徑。這個規範定義了一個用於CoRE資源發現的新衆知資源：“/.well-known/core”。
爲了資源發現的目的，實現了這篇規範的服務器必須在適當的協議默認端口上支持這個資源。但，這還是取決於包含鏈接的應用以及它們是怎麼組織的。資源“/.well-known/core”是用於返回指向服務器上資源接口入口點的鏈接的。更復雜的鏈接組織可以通過包含到服務器上其他地方的CoRE鏈接格式資源來達成，比如，爲了實現索引。當一個鏈接都沒有時，返回一個零長度的payload。這個資源的資源陳述必須是第2章中描述的CoRE鏈接格式。
CoRE資源發現接口支持以下交互：
- 在默認端口的“/.well-known/core”上執行一個GET，返回CoRE鏈接格式的可在服務器上訪問的鏈接的集合(如有)。這些鏈接也許會描述服務器上或者其他服務器上擁有的資源，或者表達其他類型的鏈接關係，如第二章中描述的。
- 過濾可能會在任何鏈接格式屬性上進行，使用如4.1章中描述的查詢字符串。比如，[GET /.well-known/core?rt=temperature-c]將請求資源類型爲temperature-c的資源。但是，不要求服務器必須支持過濾。
- 更牛逼的服務器，比如代理，可以實現一個資源目錄，通過請求其他端點的資源描述或者允許服務器POST請求到“/.well-known/core”上。但是資源目錄功能的細節就不是這篇規範的範疇了，應該要獨立規定。
4.1 查詢過濾
一個實現了這篇規範的服務器也許會認得資源發現URI的查詢部分，將其作爲返回的資源的過濾器。路徑和查詢部分合在一起應該遵從以下4層URI模板[RFC6570]：
/.well-known/core{?search*}
當變量“search”是一個單元素列表，即只有一個鍵值對時，
- 名字要不就是“href”，定義在這篇規範中的一個 鏈接-參數 名，要不就是其他 鏈接-擴展 名，並且
- 值要不就是一個不以“*”(%2A)結尾的完整值的字符串，要不就是一個後面跟着“*”(%2A)的前綴值字符串。
搜索名“href”指向的是一個鏈接在“<”和“>”間的URI引用。兩個值字符串僅在目標屬性存在時才匹配。值字符串在進行匹配前會進行百分比編碼([RFC3986]的2.1章)；相似的，任何表示爲雙引號字符串的目標屬性都會按照[RFC2616]第2.2章中的定義來解釋。完成這些步驟後，如果按位一致的話，一個匹配目標屬性的完整值字符串就匹配出來了。匹配目標屬性的前綴值字符串則是按位匹配前綴(任何字符串是自身的前綴)。前綴值字符串可以是空的；根據上面的定義，它匹配任何存在的目標屬性。要注意的是關係類型目標屬性可以包含多個值，在匹配中，每個值都必須當作獨立的目標屬性。
並不期待每個受限節點都支持過濾。不支持過濾的實現必須簡單地忽略查詢字符串併爲單播請求返回整個資源。
當使用如受限應用協議(CoAP)這樣支持多播請求的傳輸協議時，有些要特別考慮的地方。如果不支持過濾，或者過濾器不匹配，則不應該答覆帶有查詢字符串的多播請求(以免不必要的答覆風暴)。除非IP棧接口不能告知使用的是否是多播地址。
以下例子是有效的詢問URI的示例：
- ?href=/foo 匹配錨定在/foo的鏈接值
- ?href=/foo* 匹配錨定在以/foo起始的URI的鏈接值
- ?foo=bar 匹配目標屬性foo的值一字不差的爲bar的鏈接值
- ?foo=bar* 匹配目標屬性foo的值以bar起始的鏈接值，如bar或barley。
- ?foo=* 匹配擁有目標屬性foo的鏈接值
5 示例
後面是一些典型的按這種格式的鏈接描述。一個陳述中的多個資源描述相互間由逗號分隔。示例中爲了可讀性還包含了換行。儘管以下示例使用了CoAP答覆碼，這些示例同樣適用於HTTP(對應的答覆碼會是 200 OK)。
這個示例包含到兩個不同傳感器的鏈接，它們共享同個接口描述。要注意的是，這個鏈接格式的默認關係類型是鏈接中的“hosts”，它沒有rel=target屬性。因此，這個示例中的鏈接告訴我們，/.well-known/core所請求的那個原始的服務器擁有資源/sensors/temp和/sensors/light(分別是一個目標)。
REQ: GET /.well-known/core
RES: 2.05 Content
</sensors/temp>;if=“sensor”,
</sensors/light>;if=“sensor”
不管爲了可讀性而插入的換行，格式實際上看起來像這樣。
</sensors/temp>;if=“sensor”,</sensors/light>;if=“sensor”
這個示例按層次結構排列鏈接描述，入口點包括指向包含有關傳感器的鏈接的子資源的鏈接。
REQ: GET /.well-known/core
RES: 2.05 Content
</sensors>;ct=40
REQ: GET /sensors
RES: 2.05 Content
</sensors/temp>;rt=“temperature-c”;if=“sensor”,
</sensors/light>;rt=“light-lux”;if=“sensor”
查詢過濾器的示例可能長這個樣子：
REQ: GET /.well-known/core?rt=light-lux
RES: 2.05 Content
</sensors/light>;rt=“light-lux”;if=“sensor”
注意，關係類型屬性如‘rt’、‘if’和‘rel’可以有多個由空格分隔的值。一個查詢過濾器參數可以匹配這些值中的任意一個，如下例：
REQ: GET /.well-known/core?rt=light-lux
RES: 2.05 Content
</sensors/light>;rt=“light-lux core.sen-light”;if=“sensor”
這個示例展示了“anchor”屬性的用法，它關聯溫度 傳感器資源到一個外部描述和一個備選URI上。
REQ: GET /.well-known/core
RES: 2.05 Content
</sensors>;ct=40;title=“Sensor Index”,
</sensors/temp>;rt=“temperature-c”;if=“sensor”,
</sensors/light>;rt=“light-lux”;if=“sensor”,
<http://www.example.com/sensors/t123>;anchor="/sensors/temp";rel=“describedby”,
</t>;anchor="/sensors/temp";rel=“alternate”
如果一個客戶端想要發現一個特定資源的關係，他可以在anchor參數上進行一個詢問。
REQ: GET /.well-known/core?anchor=/sensors/temp
RES: 2.05 Content
<http://www.example.com/sensors/temp123>;anchor="/sensors/temp";rel=“describedby”,
</t>;anchor="/sensors/temp";rel=“alternate”
下例展示了一個大固件資源，帶有一個尺寸屬性。這個鏈接的消費者將使用‘sz’屬性來確定是否資源陳述過大，以及是否需要進行分塊傳輸。在這個情況下，一個只有64KB閃存的客戶端可能只支持16位整型來存儲‘sz’屬性。因此，應該使用一個特定的flag或值來表示‘Big’(大於64KB)。
REQ: GET /.well-known/core?rt=firmware
RES: 2.05 Content
</firmware/v2.1>;rt=“firmware”;sz=262144
6 安全考慮
這篇規範有如[RFC5988]第七章中描述的安全考慮。“/.well-known/core”資源也許會被保護，比如依據 [COAP] 9.1章，當存儲在一個CoAP服務器上時，可以使用數據包傳輸層加密(DTLS)。
一些服務器也許會爲異構的在不同程度上受信的客戶端提供資源發現服務。比如，一個輕量的控制系統可能會允許任何客戶端讀狀態變量，但是僅允許特定客戶端去寫狀態(開/關燈)。擁有認證和授權特性的服務器應該支持底層傳輸協議的認證特性(HTTP或DTLS/TLS)，並支持基於客戶端的標識和權限返回不同的鏈接列表。儘管這樣的服務器也許不會給所有請求者返回所有鏈接，不提供鏈接不意味着它就會限制對相關資源的訪問 — 一個差勁的執行器可能知道或者猜到正確的URI。服務器也可以給出假的可用資源。如果客戶端僅能從已知資源獲得信息十分重要話，則資源需要被授權。
在CoAP上對衆知鏈接格式資源的多播請求可以用於在受限網絡上拒絕服務。一個多播請求應該僅在被充分授權和加密使用時才能接受，比如，使用IPsec或者一個適當的對象加密機制。
CoRE鏈接格式轉換器應該意識到鏈接描述可能是循環的。即包含指向自己的鏈接。這些循環的鏈接可能是直接的，也可能是間接的(即，通過引用的資源)。當轉換鏈接描述和訪問循環的鏈接時應該要小心。
7 IANA考慮
7.1 衆知 ‘core’ URI
這個備忘錄將‘core’衆知URI註冊進[RFC5785]中定義的衆知URI入口中。
URI後綴：core
變更控制者：IETF
規範文檔：RFC 6690
相關的信息：無
7.2 新關係類型 ‘hosts’
這個備忘錄註冊新Web鏈接關係類型‘host’，參照[RFC5988]。
關係名：hosts
描述：對於由服務器擁有的一個資源的引用，由鏈接內容表示。
參考文獻：RFC 6690
注意：這個關係是用於CoRE的，在CoRE中，鏈接是作爲"/.well-known/core"資源陳述提取的，其是CoRE鏈接格式的默認關係類型。
應用數據：無
7.3 新因特網媒體類型 ‘link-format’
這個備忘錄爲CoRE鏈接格式註冊一個新因特網媒體類型‘application/link-format’。
類型名：application
子類型名：link-format
需求參數：無
可選參數：無
編碼考慮：二進制數據(UTF-8)
安全考慮：
請求CoAP衆知鏈接格式資源的多播請求可以在受限網絡上用於拒絕服務。只有在請求被使用 如IPsec或合適的對象加密機制 充分授權和加密的情況下，多播請求才會被接收。
CoRE鏈接格式轉換器應該意識到，鏈接描述可能是循環的，即包含到自己的鏈接。循環的鏈接可能是直接的，也可能是間接的(即通過引用的鏈接資源)。在轉換鏈接描述和訪問循環的鏈接時要十分小心。
互用性考慮：無
發佈的規範：RFC 6690
使用這個媒體類型的應用：CoAP服務器和客戶端實現來用於資源發現，以及HTTP應用將鏈接格式作爲payload。
額外信息：
幻數：
文件擴展名：*.wlnk
Macintosh文件類型代碼：
預期用途：COMMON
使用約束：無
作者：CoRE WG
變更控制者：IETF
7.4 受限RESTful環境(CoRE)參數註冊
略
8 鳴謝
略
9 參考文獻
略