日本免费全黄少妇一区二区三区-高清无码一区二区三区四区-欧美中文字幕日韩在线观看-国产福利诱惑在线网站-国产中文字幕一区在线-亚洲欧美精品日韩一区-久久国产精品国产精品国产-国产精久久久久久一区二区三区-欧美亚洲国产精品久久久久

  1. 首頁 > 云知道 > >

APP對決Web3S：探索RESTful協(xié)議之路( 二 )

云知道


來自微軟的Dare Obasanjo在題為《為什么GData/APP無法成為通用的Web編輯協(xié)議》的文章中解釋了微軟在APP中發(fā)現(xiàn)的問題，以及因此而(可能)導(dǎo)致微軟另立門戶，開發(fā)一個(gè)新協(xié)議 。在文中Dare用很長篇幅解釋了APP由于協(xié)議的約束而存在多處局限，非凡是：以下是引用片段：
與非微內(nèi)容(microcontent)的數(shù)據(jù)模型不匹配：ATOM數(shù)據(jù)模型很適合用于表示創(chuàng)作的(authored)內(nèi)容或者微內(nèi)容，諸如博客文章、鏈接列表、podcast、在線相冊和日歷事件等等 。在這些情形中，每個(gè)Atom條目要有一個(gè)ID、一個(gè)標(biāo)題、更新時(shí)間、若干作者和內(nèi)容文本，這些需求都能夠很好地滿足，而且這樣做很有道理 。但另一方面，仍然有很多在線數(shù)據(jù)并不適合這個(gè)模型 。
而且
以下是引用片段：
缺乏對條目(item)中的一個(gè)域(field)進(jìn)行更新這種小粒度更新的支持：前面已經(jīng)說過要實(shí)現(xiàn)對一個(gè)條目的編輯需要用新條目來替換整個(gè)舊條目 。客戶與服務(wù)器之間的交互的規(guī)定在當(dāng)前APP草案的第5.4小節(jié)，后面作了一些摘錄 。
最后
以下是引用片段：
對分層結(jié)構(gòu)的支持很弱：ATOM數(shù)據(jù)模型并不直接支持嵌套和分層 。你可以有一個(gè)媒體資源或者資源條目的集合，但資源條目自身不能包含資源條目 。也就是說，假如你想要表示一個(gè)含有子條目的條目，則子條目必須通過鏈接來引用，而不能內(nèi)嵌在條目中 。假如考慮到ATOM的博客聯(lián)合(syndication)和博客編輯的背景，這樣做是有道理的，比如在feed中或者編輯文章的時(shí)候把所有評論都直接包含在條目里，就不是一個(gè)好主意 。但另一方面，當(dāng)你要表示一個(gè)直接的父<->子層次關(guān)系，要是把子元素定義成一個(gè)獨(dú)立的可定位資源，對客戶來說就很繁瑣，客戶不得不總是發(fā)出兩次甚至更多次調(diào)用才能得到所需的數(shù)據(jù) 。
屬于IETF APP工作組的Bill de h觬a對Dare的說法回應(yīng)道：
以下是引用片段：
原則上講，我很歡迎協(xié)議的實(shí)現(xiàn)者們根據(jù)他們的需要反過來推動ATOM協(xié)議的發(fā)展 。然而，聲稱GData/APP已經(jīng)失敗實(shí)在是不知所云，非凡是提到的問題，有些是被審慎地排除在設(shè)計(jì)目標(biāo)之外的(就目前而言) 。假如這些就是微軟碰到最嚴(yán)重的問題，我會很驚奇于目前APP的總體設(shè)計(jì)情況良好 。根據(jù)他的思考的深度和所提到的微軟內(nèi)部的討論，我更驚奇于Dare竟然沒有提到以下兩個(gè)問題：1、更新的斷點(diǎn)續(xù)傳(Update;resumption)：有的客戶需要將數(shù)據(jù)分成小片段來上傳的能力 。除開用戶體驗(yàn)和節(jié)省帶寬的理由，這對有些收費(fèi)方式來說也很重要;不然用戶要為每次上傳失敗買單 。APP從未涉及這個(gè)方面的支持;雖然用更普通的HTTP也可以做到，但要想得到合理的客戶支持，你至少應(yīng)該要求把它寫進(jìn)RFC 。2、批量(batch)和multi-part更新：ATOM語法工作組已經(jīng)考慮過這項(xiàng)特性但決定放棄 。原因是要處理批量上傳(或稱作“打包運(yùn)輸(boxcarring)”)會變得難以預(yù)計(jì)的復(fù)雜 ?！鞍l(fā)送一批條目”說起來很簡單，但事實(shí)并非如此 。不過未來仍然應(yīng)該再繼續(xù)考慮這些問題 。
Joe Gregorio(另一位主要的APP貢獻(xiàn)者)，在Yaron的文章后的評論中問道：以下是引用片段：
我更希望知道的是，為什么當(dāng)你碰到這些問題的時(shí)候，不把它們拿到工作組里討論?顯然當(dāng)你開始搞Web3S的時(shí)候APP協(xié)議還沒定案，假如你認(rèn)為你發(fā)現(xiàn)了APP的真正弱點(diǎn)，雖然后續(xù)討論證實(shí)你是錯(cuò)的，為什么不在我們發(fā)布協(xié)議之前提出來?
IBM的Sam Ruby，RESTful Web Services的作者之一，認(rèn)為這個(gè)打算支持“結(jié)構(gòu)化的、數(shù)據(jù)定義的和可搜索的Web”的協(xié)議，根本沒有支持Web、數(shù)據(jù)定義和搜索：
以下是引用片段：
這份文檔中定義了兩個(gè)新媒體類型(Application/Web3S xml和Application/Web3SDelta xml)、兩個(gè)新URI協(xié)議和一個(gè)新HTTP方法(UPDATE) 。我沒有找到任何對二進(jìn)制數(shù)據(jù)的討論，事實(shí)上所有東西都是用XML;infoset的語言來定義的 。既然所有數(shù)據(jù)都必須屬于某個(gè)命名空間，而這些命名空間必須用新的URI協(xié)議來定義，那么我們可以得出結(jié)論，沒有任何現(xiàn)存的XML文檔可被Web3S直接支持 。Web3S數(shù)據(jù)更進(jìn)一步被局限為一個(gè)自我封閉的樹 。Web3S中完全沒有超鏈接的一般概念，無論是對外部數(shù)據(jù)的超鏈接，還是指向樹中另一部分的超鏈接 。要遍歷這些數(shù)據(jù)，你必須了解程序所采用的特定的數(shù)據(jù)定義 。

推薦閱讀