2017-04-20 51 views
3

我正在設計RESTful Web服務以公開SOA體系結構中的功能。服務客戶登錄到企業內部網,擁有客戶名稱,ID和其他技術信息(與業務無關)。如何使用客戶端信息的服務器端日誌記錄功能設計RESTful服務

我有一個要求,即所有對RESTful服務的調用都必須被記錄下來,並且必須包含客戶端的「not business」信息(id,應用程序名稱,登錄用戶等)。

我想收集JSON對象「technicalData」中的所有技術信息和另一個JSON對象「dto」中PUT/POST的業務數據(數據傳輸對象)。

將此信息放入GET,POST,PUT,DELETE的請求正文中是否正確?

這些信息在GET/DELETE身體沒有語意的要求,因爲它們只用於登錄目的see this answer on SO

例子:

GET /books?author=AUTHOR 

{ 
    "technicalData": 
    { 
     "id": "...", 
     "loggedUser": "...", 
     "applicationName": "..." 
    } 
} 

POST /books 

{ 
    "technicalData": 
    { 
     "id": "...", 
     "loggedUser": "...", 
     "applicationName": "..." 
    } 
    "dto": 
    { 
     ... 
    } 
} 

PUT /books/ID 

{ 
    "technicalData": 
    { 
     "id": "...", 
     "loggedUser": "...", 
     "applicationName": "..." 
    } 
    "dto": 
    { 
     ... 
    } 
} 

DELETE /books/ID 

{ 
    "technicalData": 
    { 
     "id": "...", 
     "loggedUser": "...", 
     "applicationName": "..." 
    } 
} 

回答

3

不,您不應該在每個請求的主體中傳遞該信息。您肯定不應該在GET和DELETE調用中將其傳遞給電線,因爲這違反了規範:

發送GET請求上的有效內容主體可能會導致一些現有的實現拒絕請求。 (RFC 7231

在DELETE請求上發送有效內容主體可能會導致一些現有的實現拒絕請求。 (RFC 7231

這樣的元信息屬於頭文件。想必您使用Authorization標題或其他方式來識別用戶?這會給你用戶名。如果沒有,也許From標題將是一個適當的地方來存儲它。也許User-Agent可以用來指定應用程序。或者,看看使用JWT,它可以讓你嵌入任意信息。

+0

我認爲這是正確的答案,我會接受這一點。最後一個問題是:如果服務提供者已經開發了一個「框架」來讀取正文請求的JSON部分中的那些數據?什麼是最佳選擇:將所有端點更改爲POST(違反REST,但考慮到所有請求都是Intranet並且不可索引,可緩存)或迫使提供者遵守更大優點的標準?謝謝您的回答。 – Dinux

+0

您應該在接受其他答案之前留出更多的時間。如果一個人已經被接受,有些人會被勸阻回答。至於你的問題,這是介於基於意見和無法回答之間的問題。我的意見是,如果有一個客戶,只有一個客戶,你可以做任何你想做的事。我不確定誰是「提供者」在這個問題中,但如果沒有那麼多的信息,我更喜歡使用標題和/或JWT。 –

+0

你說得過早,但在這種情況下,恕我直言,你給了一個完整的答案,這正是我正在尋找的。事實上,我的客戶已經使用JWT令牌,但他決定將所有端點「設計」爲POST並將這些數據放在主體中。我對此不滿意,但我會活下來。非常感謝。 – Dinux

0

通常稱爲信息「technicalData 「不通過請求調用在客戶端和服務器之間共享。你應該只共享一個標識當前會話的請求令牌。令牌將在服務器上與已登錄的用戶相關,等等......

+0

這是客戶的要求。服務駐留在ESB中間件上,該中間件不知道類型,登錄的用戶,BPM事務ID和其他外部信息。 – Dinux

+0

如果服務不知道類型,用戶登錄,那麼你不應該記錄這個信息,但只有IP和時間戳。 – ADIMO

+0

這是客戶的要求,我不能說我不想傳遞已經存在的體系結構規範所需的日誌信息。 – Dinux