2011-12-21 7 views
1

私はWebサービスに関する同僚との議論をしていました。今私たちはどちらも、Webメソッドは単一の責任の原則に従って1つの責任しか持たないことに同意しますが、サービス全体についてはどうですか?私はいつもWebサービスをゲートウェイと見なしていましたが、彼の議論では、Webサービスに機能的にまたはドメインの観点から異なる方法を持つメソッドがある場合、それらのメソッドは完全に別のWebサービスに格納する必要がありました。私は、コミュニティがこの問題について何を言わなければならないかを見たいと思っています。Webサービスに複数の責任があることは適切ですか?

機能的に異なるメソッドを持つWebサービスを異なるサービスとURLに格納する必要がありますか?

OR

万一機能的に異なるが、ゲートウェイのコンセプトによって関連している内部ゲートウェイ家の方法を検討していますWebサービス?

+2

これはhttp://programmers.stackexchange.comに移行する必要があります –

+0

私はそれを内部ゲートウェイ...何らかのコンテキストとして使用する方法についてもう少し詳しく教えてください。 @Erik - 同意 –

+0

@RalphWillgossは内部ゲートウェイによって、私は非公開のウェブサービスを意味し、データベースなどを変更するために公にアクセス可能なサイトやサービスから呼び出されることを意味します。 –

答えて

1

これは意見の問題ですが、私たちはC#のクラスライブラリと同じガイドライン(私たちは.NETショップです)を使用してWebサービスを構造化することを選択しました。同様のfuncitonalityは、同様のWebサービスに入り、各Webサービスで何を期待するかを明確に定義します。

  • RetailLocationServices
  • EmployeeInformationServices
  • 金融サービス
  • などどのように1つのURLのconsitsモデル、その後、機能分野について
0

:あなたは省略することができ

http://api.<yourdomain>/1.0/Finance/ 
http://api.<yourdomain>/1.0/Users/ 
http://api.<yourdomain>/1.0/<FunctionalArea>/ 

直接のバージョン必要に応じてory。 APIを使っている私の経験では、別のバージョンを展開したいと思っています。クエリ文字列のパラメータでこれを行う人もいます。私は、呼び出し元への可視性のためにurlで好きです。

サービスの開発を垂直方向にスライスすることができます。したがって、1つにアップグレードしても他のサービスには影響しません。自動ビルドマジックの中には、それらを展開するのに役立つものもあります。

関連する問題