如果生成操作比較耗時，可以通過異步處理， 即把生成的文件以用戶為單位保存成列表，然后在生成功能時以某種方式，（可以是websocket，也可以是輪詢）等處理完了，彈出文件下載列表。至于服務(wù)器端成的文件，可以通過servlet或者nginx等直接提供下載即可。

給個提示性思路，我沒有試過。

1. 是給后端做，后端生成一個word 文件，前端直接去下載這個文件就可以了。后端生成word文件技術(shù)，網(wǎng)上一艘就有，前端下載文件技術(shù)網(wǎng)上也非常多。
2. 前端生成word文件，然后導(dǎo)出。前端生成word肯定用插件（自己寫很難），我不知道有沒有這個插件，得好好找。

建議是第一種方案，技術(shù)都成熟，而且如果word特別大的化，前端抗不住。

這個感覺和平常都一樣吧，后臺根據(jù)數(shù)據(jù)生成Word文件，寫入響應(yīng)中，設(shè)置響應(yīng)頭。

這個問題分兩部分，設(shè)計和實現(xiàn)。

設(shè)計上，我覺得有必要講下 RESTful 里很重要的一點

誤區(qū)：URL 帶 .json 后綴

我們經(jīng)常設(shè)計出這樣的接口：

/api/users.json
/api/users/1.json

實際上這樣是不規(guī)范的。

在 RESTful 風(fēng)格中，URL 只指定訪問的資源，不指定其表現(xiàn)狀態(tài)。

也就是說，我的 /api/users/1 應(yīng)該只表示我想要訪問 id=1 的 User，而不指定服務(wù)端會返回給我 json 還是別的格式比如 xml。

使用 Accept 和 Content-Type headers 來指定資源的表現(xiàn)狀態(tài)。

上述接口規(guī)范的形式應(yīng)該是：

URL: /api/users/1
Headers:
  Accept: application/json

所以，設(shè)計你要的這個接口，它的 URL 應(yīng)該和前端請求這份數(shù)據(jù) json 的 URL 相同，而在 header 中指定 Accept 為 word 文檔的 MIME Type。

如果這樣規(guī)范化代價太大

比如你們的系統(tǒng)已經(jīng)有很多接口，全部改成規(guī)范的很麻煩，那么還有一種差不多 RESTful 的設(shè)計方案。
設(shè)計如下接口：

POST /api/xxx/docs

注意要用 POST，原因自己體會下應(yīng)該能明白。

第二點，實現(xiàn)上，用庫。