要將問題置於某個上下文中，揭示Web服務的系統在內部使用GUID作爲所有實體的標識符。在公共數據集成Web服務中使用GUID作爲標識
在這種情況下，在設計面向公衆的數據集成Web服務時（主要用於從系統導入或導出數據到其他外部系統），您認爲在使用內部標識符服務的界面？
有了這樣的解決方案，Web服務的導出方法將返回用GUID標識的dto，並且導入方法會接受類似的dto - 我假定外部系統將負責爲新實體生成新的GUID。
這種方法可能會遇到什麼樣的潛在問題？
的系統和Web服務的技術堆棧是.NET/WCF/SOAP
首先，讓我們來看看更通用的「我怎麼建立一個公共的API」的問題，我的第一運動是確定哪些信息是服務消費者所需要的。我還會查看對象模型中是否存在公司特定的命名。然後，我創建一個服務模型（數據協定，如果您希望WCF特定的）與我想向用戶顯示的視圖相匹配。這包括一個唯一的密鑰，它比GUID/int（實際派生的主鍵）更經常是一個SKU字符串（人類可讀密鑰），因爲SKU是公共的，並且在數據庫中存儲的方式不是。所以，一般來說，我不會公開這些主要關鍵概念，如果這就是GUID。
現在的問題是「你看到這種方法的問題」。我將着重於更一般的概念，以便您做出更明智的決定，因爲沒有100％正確/錯誤的答案。
只要這是機器對機器和GUID的使用是兩個系統都知道的事情，我沒有看到任何關於這種方法的特別可怕。如果這個終極版轉到了一個GUID必須與之交互的人類可讀系統，那麼你就有一個問題。
系統的一個潛在問題是將您自己的主要關鍵信息暴露給客戶或客戶端系統，他們不必瞭解這一級別的詳細信息。如果這實際上是「供應商選擇清單」的「半公開」，那麼「風險」可能會更小。這是我看到的主要問題。
有人可能會爭論GUID（128位）與較小標識符的權重，但這是一個虛假答案IMO，因爲網絡延遲超過發送多個字節作爲請求參數。
感謝您的深思。事實上，這項服務並非向公衆開放，而是嚴格在客戶的IT基礎設施中使用。在絕大多數情況下（可能不包括支持工作），它將是機器對機器。 我同意，在一般情況下公開這些私人和低級別的數據不是一種好的做法，但也許在封閉的環境中，問題可能並不那麼嚴重。 – 2011-06-06 09:18:30
除非您對數據非常幸運，否則您必須拿出1）一套可選的標識符（可能或可能不必是人類可讀的），2）是唯一的，3）必須翻譯往返於你的內部。如果它們不必是人類可讀的，並且假設你有太多的數據來手動選擇新的ID並且不能保證其他數據字段的唯一性，那麼我認爲使用一個大的（比如說128位？ ：P）號碼作爲您的外部ID。 – shambulator 2011-06-03 21:28:19