2

毫無疑問,RESTful是流行詞,在很多情況下似乎是切肉刀設計模式。我終於想知道它是否與我所做的事情相關(如果我們忘記了它在某些RFC中我們試圖迴應的事實;))。爲公共Web服務/ API定向RESTful設計總是相關的嗎?

首先我主要處理確定的至少3個參數,可能高達10

思考例如約一網絡API執行聲音效果和格式轉換(均衡的動態數據,回聲,音量,速度......)。您需要發送您的憑證,一組未被確定的效果名稱和設置以及均衡聲音。

的URL可以是像effectMaker /回聲/ 10PCT /均衡器/ 20kHz的/ -10pct /輸出速率/ 192kbps的/

  • 在HTTP頭中的一些參數(例如響應格式)

  • 身體的聲音。

因此,函數是由http方法+ url根和參數在body,url tail和header中定義的。看起來不太方便,對我和開發人員來說都不是很方便,我也沒有發現我的API

除此之外,由於我的大多數用戶請求都是唯一的,所以緩存功能不會產生影響。

因此,我問你是否錯誤,認爲我應該嘗試整合使REST「哲學」(無狀態,可發現,...)中的sens的東西,但只是放棄某些部分它是毫無意義(可緩存)或使API奇怪?例如,當你在主體中推送一些數據並希望獲得轉換後的數據時,我應該堅持使用HTTP動詞嗎?

對我來說,當你管理/使用通過一個非常簡單的路徑訪問的在線數據庫項目時,RESTFull設計看起來似乎很敏感。當您的API創建/轉換可能獨特使用的數據時,它似乎很不方便。當你有十幾個接受各種值的參數時,看起來很痛苦。

然而,SOAP和XML-RPC標準是在我看來相當難看......

因此,它是不好使RESTlike或當它似乎更明智使用JSON參數/響應相關AsRESTasRelevant設計?

任何意見的標準遵循在我的情況?

乾杯,

文森特

回答

0

REST不是一個理念。這是一種建築風格 - 設計系統以符合某些goals的一種方式。如果這些目標不是你的,那麼REST是一個壞主意。如果是,那麼REST是個好主意。我們不知道你的目標是什麼,所以我們不知道REST是否適合你。

這下位並沒有真正與REST做的,這是比較通用的網絡API設計,

不要使用URL包含處理指令。就像你說的那樣,對於非平凡的系統來說這是完全不實用的。要麼支持Multipart請求包含處理指令在一個部分和音頻文件在另一部分,或將文件上傳和處理指令視爲兩個單獨的請求。你甚至可以同時支持。

只是spitballing,如果我試圖設計這個作爲RESTish API,我可能會開始不久

POST /audio-files 

request: 
Content-type: audio/midi 
<audio file> 

response: 
201 Created 
Location: http://example.com/audio-files/12 

-

POST /audio-files 

request: 
Content-type: multipart/mixed; boundary="simple boundary" 
--simple boundary 
Content-type: application/json; charset=us-ascii 
{ 
    "echo": "true", 
    ... 
} 
--simple boundary 
Content-type: audio/midi; charset=us-ascii 
<audio file> 
--simple boundary-- 

response: 
200 Ok 
Link: <http://example.com/audio-files/12>; rel="audio-file" 
<altered-audio-file> 

-

POST /altered-audio-files 

request: 
Content-type: application/json; charset=us-ascii 
{ 
    "audio-file": "http://example.com/audio-files/12" 
    "echo": "true", 
    ... 
} 

response: 
200 Ok 
<altered-audio-file> 

這把聲音文件和更改的音頻文件作爲資源。這樣,當有人想要在同一個文件上執行八次轉換時,您可以通過保持上傳的音頻文件節省連線時間,並且如果您稍後選擇這樣做,則可以選擇保留更改後的音頻文件。如果您想跟蹤請求,則可以通過添加第三個端點(可能爲/audio-requests)輕鬆完成此操作。