API和Rails - 最佳途徑

目前，我的應用程序使用FlickRaw gem從Flickr中提取數據。我想重新整理它的一部分，並刪除FlickRaw依賴。API和Rails - 最佳途徑

所以，我現在使用的是HttParty並直接調用Flickr API方法。

我已經做了一個Flickr類，並在那裏我有self.collection，self.photoset等方法來拉相應的東西。

我擔心的是，從我的應用程序中實際需要使用這些方法與Flickr集成的位置，我必須調用Flickr.collection（id）。如果Flickr突然被抓住存在，我將不得不去找到所有對Flickr的引用並改變它們。我寧願將我的Flickr類重命名爲類似PhotoHost的類，並在其中有方法稱爲Flickr，但由於Flickr特定部分都在一起，如果需要，未來應該更容易進行更改。這聽起來是一個明智的方式來處理這個問題嗎？你會怎麼做呢？

此外，該類中的方法是否會與真實的API方法直接進行1：1映射，還是會在您將應用程序中的其他位置使用之前創建自己的方法並構建一組實際需要的數據，或者您只需將flickr響應發送給其他地區並在那裏處理？ - 實際上，輸入後似乎最好的方法是編寫一個名爲（例如）self.photos_for_album（album_id）的方法，然後調用相應的flickr API方法來構建一組照片，然後使用該方法回報。我想這可以讓我在應用程序周圍編寫其他代碼來與照片進行交互，如果我從Flickr更改照片主機，那麼只要新方法以相同格式返回數組，所有應該都是好的。

對不起，這個問題一直是一個問題，但我會非常有興趣聽到別人會怎麼做呢？

來源

2012-08-12 rctneil

你真正想要使用的是類似於Strategy或Adapter模式。您應該創建一個FlickrPhotoHost模塊，實現了您的應用意義的方法（不一定1-1 Flickr的API）：

module FlickrPhotoHost 
    def get_albums 
     # fetch from flickr 
    end 

    def get_photo(album_id) 
     # fetch from flickr 
    end 
end

然後，你應該有一個PhotoHost類，包括這個Flickr的適配器：

class PhotoHost 
    include FlickrPhotoHost 
end

然後在你的應用程序中使用它的任何地方。

source = PhotoHost.new 
album = source.get_albums.first 
photos = source.get_albums(album.id) 
# and so on...

在flickr上死了，你可以用InstagramPhotoHost替換爲：

module InstagramPhotoHost 
    def get_albums 
     # fetch from instagram 
    end 

    def get_photo(album_id) 
     # fetch from instagram 
    end 
end

，應用程式的其餘部分，你需要改變的唯一部分是PhotoHost：

class PhotoHost 
    include InstagramPhotoHost 
end

這對於一個主機來說可能有點矯枉過正，但是想象一下你想同時實現Instagram和Flickr？讓PhotoHost運行時決定：

class PhotoHost 
    def initialize type 
    extend case type 
     when :instagram then InstagramPhotoHost 
     when :flickr then FlickrPhotoHost 
    end 
    end 
end

而且在實例，你可以爲Flickr相冊做到這一點：

PhotoHost.new(:flickr).get_albums

然後BAM，Instagram的：

PhotoHost.new(:instagram).get_albums

來源

2012-08-12 13:04:09

謝謝你。我會在後面詳細介紹它，但看起來很好主意 – rctneil 2012-08-12 15:14:56

抽象到更高層次的抽象往往是一個好主意。例如，您的應用將使用PhotoHost而不是Flickr。

反對的觀點是要提防早熟優化。例如，您的應用程序是否有積極的需求來替代Flickr？你還有什麼可以花時間爲你的應用程序和用戶提供更多功能/好處？

另外：想想你的抽象PhotoHost如何使您的應用程序一次與多個實現對話（能夠輕鬆顯示兩個閃爍和InstaGram照片）。

您還詢問了有關API的方法。

我會小心改變它的運動方法。希望有人想到Flickr API方法。

但是您應該改變方法來添加您的應用可以使用的其他功能。例如，如果Flickr api是同步的，那麼您可能需要添加一組異步方法，以便在最終用戶完成所請求的操作的同時，讓最終用戶進行多任務（或至少獲得反饋）。

來源

2012-08-12 13:31:43

謝謝。想想我將改爲PhotoHost。這隻適用於我的個人網站。沒有外部用戶，只是爲了幫助我在自己的時間裏學習如此完成。我真的不認爲我會因爲任何原因需要換出Flickr，但我可能會抽象出一些。這比我目前與Flickr的緊密1：1集成要好。感謝您的建議。 – rctneil 2012-08-12 15:16:34

API和Rails - 最佳途徑

回答

相關問題