良い一日、
複数企業の組織向けの Web API ソリューションの開発を開始します。私は、組織全体のあらゆる企業がすべての有用なデータを利用できるようにしたいと考えています。
このソリューションで多くの成長が見込まれることを考えると、最初から適切に構成されていることを確認したいと思います.
いろいろなサービスを会社ごとに整理し、さらにアプリや機能ごとに整理したい。
したがって、URL に関しては、次のような構造をターゲットにする必要があります。
/company1/application1/serviceOperation1
または、名前空間を活用する方法はありますか:
/company2.billing/serviceOperation2
会社ごとにソリューションに個別の Web API プロジェクトを作成することはできますか? そうすることに価値はありますか？
主観的になりすぎないことを願っていますが、私が見た例は範囲が狭く、私のソリューションが最終的に多くの Web API サービスを公開していることが実際にわかります。
ありがとう、
クリス
コード行を書く前に、情報がどのように保護され、展開され、バージョン管理され、会社の文化がどのようにされているかを調べます。
同じセキュリティ メカニズム (プロトコル、証明書、モードなど) は、すべての会社や部門で共有されますか?
If they are shared then there is a case for keeping them in the same solution
サービスによって異なる量の負荷が発生し、パッチ適用スケジュールが異なる複数のサーバーにデプロイされますか?
If the services are going onto different servers then they should probably be split to match
展開とその後のバージョン管理のスケジュールは、サービスごとに独立していますか? それとも、すべてのサービスが常に一緒に展開されますか?
If they are versioned independently then you would probably split the solution accordingly
会社はどのくらいの頻度でアプリケーションを再構築して維持していますか?
If the company is constantly restructuring without you would probably want to split the services by application. If the company is somewhat stable and focused on changing the application capabilities then you would probably want to split the services by division function (accounts, legal, human resources, etc.)
アクセスする URL については、上記の回答から自然に流れてくるはずです。お役に立てれば。