タグ付けされた質問 「api」

20〜30の独立したモジュール/ソリューションがあります。これらのそれぞれには、クラス、コンポーネントなどが異なる7〜10のプロジェクトがあります。これらはすべて社内で使用されます。 私たちの問題は、1つのモジュールに変更を加える場合、このコードにアクセスしている他のすべてのモジュールを確実に更新する必要があることです。コードベースが異なるため、これを知るのは困難です。 APIのすべての外部使用がどこにあるかをどのように文書化できますか？あるいは、小さな変更が他のモジュールを壊すのを防ぎますか？

8 documentation  api  configuration-management  change-management 

要件が次のようなクライアント向けのシステムを設計しています。 彼らはJSONファイルをアップロードします（1つのオブジェクト/行） JSONオブジェクトをペイロードとしてAPIを呼び出す 各API呼び出しの状態（成功/失敗）をデータベースに記録する 失敗した場合は、1回再試行します。 セロリとsqliteデータベースをバックエンドとして使用して構築することにしました。JSONの行の数は多くなく、メモリに収まる可能性があります。個々のコンポーネントはすべて正常に動作していますが（ファイルのアップロード、ファイルの読み取り、APIの呼び出し、dbへの書き込みなど）、セロリを使用したタスクのディスパッチの全体的なアーキテクチャについてはわかりません。 ファイルにN行あるとすると、次のようになります。 オプションA： result列（最初はnull）を持つデータベースにN個のオブジェクトを作成します。 N個のセロリタスクを作成し、オブジェクトIDをパラメーターとペイロードとして渡します サブタスクにAPIを呼び出しさせ、オブジェクトの結果フィールドを成功/失敗に更新します。 失敗した場合にセロリの再試行機能がAPIを再度呼び出そうとするようにします。 オプションB： result列（最初はnull）を持つデータベースにN個のオブジェクトを作成します。 1つのセロリタスクを作成し、N個のオブジェクトIDとN個のペイロードのリスト全体を渡します N個のオブジェクトすべてをループして、各ステップの結果でデータベースを更新します。 前のタスクが完了すると、別の1回限りのセロリタスクが起動され、失敗した結果を持つすべてのオブジェクトのデータベースが読み取られて再試行されます。 オプションAは、その単純さのために優先していますが、スケジュールできるセロリタスクの数の制限と、ブローカー（RabbitMQ）がそれを処理するかどうかはわかりません。オプションBの場合、大きなリスクは、セロリタスクが何らかの理由で何らかの行Mで終了した場合、後続のすべてのオブジェクトが試行されることはないということです。 これらの2つについての考え、または3番目に優れた代替案があるかどうか。

8 database  python  api  scheduling  rabbitmq 

私の質問は、REST APIを集約またはグループ化するベストプラクティスについてです。多くの異なるベンダー、データソースなどがあるシナリオがあり、REST APIをグループ化することは、システムを保守可能に保つために非常に意味があると思います。 他のシステムで同じエンティティを作成するために、他の多くの（類似した）API呼び出しをトリガーする単一のAPI呼び出しがある多くのシナリオがあります。たとえば、エンティティ "user"の例： フロントエンドがREST APIを呼び出す：PUT ... / user 私が想定しているのは、上記のAPIをリッスンするコードが複数のREST PUT呼び出しを行って、ベンダーA /ユーザー、ベンダーB /ユーザー、ベンダーC /ユーザー、内部システムA /ユーザー、内部システムB /ユーザーなどを呼び出すことです。 このような： +-------------------+ +--------+ PUT +-----------+ CALL | Vendor A API | | | +-------> | user +--------> | | | | | +-----------+ +-------------------+ | | | | Front | PUT +--------++ PUT …

8 architecture  rest  api 

さまざまな部門間の使用状況を追跡したり、アクセス制御を行うために、アクセストークンを利用するAPIを構築しています。私の計画は、HTTP動詞を適切に利用することです- GET情報の取得、POST追加、DELETE削除などを行います。 私の質問は、GET呼び出しでアクセストークンをどのように処理する必要があるかです。 オプション1： クエリ文字列の一部としてアクセストークンを提供することです/api/users/?token=ACCESSTOKEN。これで私が抱えている問題は、ACCESSTOKENがサーバーログに表示されることです。このメソッドは、本文を介してトークンが渡されるPOSTまたはDELETEリクエストとも異なります。 オプション2： （POSTリクエストで行うように）リクエストに本文を指定します。パラメータの1つはトークンです。ここでの問題は、社内の他の開発者が、データを渡しているため、これは「真のGETリクエスト」ではないと言っていることです。彼らが呼び出すURLは単純にこのように/api/users/なりtoken=ACCESSTOKEN、本文内に提供されます。 オプション3： 使用GETを中止し、すべてをに強制しますPOST。これらのAPI呼び出しの多くでは、新しいリソースを作成していないため、このアイデアは好きではありません。私は単に、承認が必要なAPIの背後にあるデータを返すだけです。 私が見当たらない、または調整する必要があるオプションはありますか？私はオプション2が好きですが、他の部門の開発者の懸念に敏感です。

8 design  design-patterns  api  api-design 

あるプログラムへのプラグイン（Eclipseに類似）であるソフトウェアモジュールがあり、他のプラグインが呼び出すことができるAPIが欲しいと想像してください。あなたが別のAPIモジュール、持っていると思いますので、あなたのプラグインは、自由に利用できないではなく、実装モジュールAPIクライアントのみAPIモジュールをコンパイルすることができ、 -自由に利用でき、他のプラグインが直接へのリンクはする必要が唯一のものですがビルドパス上。APIが互換性のある方法で進化するように制限されている場合、クライアントプラグインはAPIモジュールを独自のjarに含めることもできます（Error存在しないクラスがアクセスされることによるsの可能性を防ぐため）。 ライセンスは、APIと実装を別々のモジュールに配置する唯一の理由ではありません。実装モジュールが複雑で、独自の無数の依存関係がある可能性があります。Eclipseプラグインには通常、内部パッケージと非内部パッケージがあり、非内部パッケージはAPIモジュールに似ています（どちらも同じモジュールに含まれていますが、分離することができます）。 私はこれのいくつかの異なる選択肢を見てきました： APIは、実装とは別のパッケージ（またはパッケージのグループ）にあります。APIクラスは、実装クラスを直接呼び出します。API は、実装なしでソースからコンパイルすることはできません（まれなケースでは望ましいことです）。実装がインストールされていない場合、APIメソッドの呼び出しの正確な影響を予測することは簡単ではありません。そのため、クライアントは通常、これを回避します。 package com.pluginx.api; import com.pluginx.internal.FooFactory; public class PluginXAPI { public static Foo getFoo() { return FooFactory.getFoo(); } } APIは別のパッケージにあり、リフレクションを使用して実装クラスにアクセスします。APIは実装なしでコンパイルできます。リフレクションを使用すると、パフォーマンスが低下する可能性があります（ただし、問題がある場合はリフレクションオブジェクトをキャッシュできます。実装が利用できない場合の動作を簡単に制御できます。 package com.pluginx.api; public class PluginXAPI { public static Foo getFoo() { try { return (Foo)Class.forName("com.pluginx.internal.FooFactory").getMethod("getFoo").invoke(null); } catch(ReflectiveOperationException e) { return null; // or throw a RuntimeException, …

8 java  api 

作業しているWebベースのアプリケーション用のシンプルなRESTful APIを構築しています。ドメインモデルを公開するための最良の方法について考えています。 Userクラスがあり、JSONレスポンスにさまざまなユーザープロパティを提供したいとします。セキュリティと帯域幅の問題のため、モデルのすべてのプロパティ（DateCreated、PasswordHashなど）を公開したくないのは明らかです。 私はデータ転送オブジェクトを読みましたが、これが進むべき道かどうか疑問に思っています。私が正しい場合、たとえば、ユーザーモデルをユーザーDTOに渡し、そのDTOが選択したユーザープロパティの公開のみを許可することを確認できます（これは、モデルをパブリックAPIから分離するのにも役立ちます）。 この解決策は適切ですか、またはこれについてより良い方法がありますか？ ありがとう。

8 language-agnostic  api  domain-model 

私が書いたソフトウェアを詳細に文書化しようとしています。SASは高レベルであり、APIをカバーしていません。オンラインでSDSの例をいくつか見つけましたが、形式に傾向は見られません。 ソフトウェア設計仕様を作成するための一般的なガイドラインがあるかどうか、または最良のアプローチは何ですか？

8 documentation  api  uml  design 

私が取り組んでいるプロジェクトでは、ウィジェットに関するメッセージをメッセージキューを介して送信し、XMLとしてキューにシリアル化します。XMLスキーマには、ウィジェットタイプ、コマンド名、宛先など、これらのウィジェットメッセージのすべてのタイプに共通のプロパティのタグが含まれています。また、任意のサイズのキーと値のペアのリストを含めて、特定のタイプのウィジェットメッセージにのみ関連するプロパティを保存することもできます。WidgetMessageクラスは、このデータをカプセル化し、WidgetMessageXmlWriterそしてWidgetMessageXmlReaderクラスは、XMLにしてから直列化を提供します。 特定のメッセージをカプセル化するクラスをいくつか作成しました。たとえばFooPlaySoundMessage、「Foo」ウィジェットやBarSetLightPatternMessage「Bar」ウィジェットなどです。これらはそれぞれ、クラスとの間で変換するためのToWidgetMessageインスタンスメソッドとFromWidgetMessage静的メソッドを持っていますWidgetMessage。メッセージの各ファミリは、そのウィジェットタイプの抽象クラスから継承されます。たとえばFooMessage、and BarMessageはWidgetMessageMappingクラスから継承されます。これは、変換のためにサブクラスによって使用される共通のメッセージプロパティと保護されたメソッドを格納します。これらのクラスはWidgetMessage、キーと値のコレクションプロパティと関連するメソッドを継承したくないため、継承しません。単純なキャストではなく変換が必要です。 私はAPIの単純さを気に入っています（例：）が、FooPlaySoundMessage msg = FooPlaySoundMessage.fromWidgetMessage(widgetMessage)機能を共有するために基本クラスで保護されたメソッドを使用し、それを公開するために静的メソッドを使用しなければならないという事実は、別個のクラスまたは2つが関与する必要があるのか​​と疑問に思いますここ（WidgetMessageXmlWriterおよびと同様WidgetMessageXmlReader）。一方、OOPのポイントの一部は、データとメソッドをグループ化して、「ダムデータオブジェクト」を回避することだと思いました。 それで、データオブジェクトに変換メソッドを追加することによって正しいアイデアを持っていますか、それともその機能を別のクラスに抽出する必要がありますか？ 更新： 上記の現在の設計の試みのすべての詳細において、私が解決しようとしている問題を十分に明確に説明していなかったと思います。 要約すると、強く型付けされたプロパティと、他のカスタムデータを格納するためのキーと値のペアのコレクションを持つ「ジェネリック」DTOクラスがあります。キーと値のペアが厳密に型指定されたプロパティに置き換えられていることを除いて、汎用DTOと同じデータをすべて格納するカスタムデータのセットごとに、いくつかの特殊なDTOクラスが必要です。これら2つのタイプのDTO間で変換するための最良の設計は何ですか？

8 object-oriented  api  api-design 

イベントリスニングインターフェイスを提供するAPIの設計では、リスナーの追加/削除の呼び出しを処理する方法が2つ競合しているようです。 addListenerを複数回呼び出しても、1つのリスナーのみが追加されます（セットに追加するなど）。removeListenerを1回呼び出すだけで削除できます。 addListenerを複数回呼び出すと、毎回リスナーが追加されます（リストに追加するなど）。removeListenerへの複数の呼び出しでバランスを取る必要があります。 私はそれぞれの例を見つけました：（1）-ブラウザーのDOM addEventListener呼び出しはリスナーを1回だけ追加し、同じリスナーを2回追加する要求を静かに無視します（2）-jQuery .on動作はリスナーを複数回追加します。 SWTやSwingイベントリスナーなど、他のほとんどのリスナーAPIは（2）を使用しているようです。（1）を選択した場合、同じリスナーを2回追加する要求があったときに、通知なしに失敗するのか、エラーで失敗するのかという問題もあります。 私の実装では、よりクリーンなセットアップ/ティアダウンタイプのインターフェースを提供し、「セットアップ」が意図せずに2回行われ、私が見たほとんどの実装と一致するバグを明らかにするため、私は（2）に固執する傾向があります。 これは私の質問につながります-他の実装に向いている特定のアーキテクチャまたは他の基本的な設計はありますか？（つまり、なぜ他のパターンが存在するのですか？）

8 design-patterns  api 

私は現在プロジェクトに取り組んでいます。そこでは、クラウドコンピューティングを使用する2つの特定のITシステムの要件を分析して、クラウドAPIを取得する必要があります。言い換えれば、私はこれらのシステムがクラウドAPIに対してどのような要件を持っているかを分析し、彼らが現在の目標を達成しながら、それを切り替えることができるようにする必要があります。 プロジェクトAの非公式な要件の例を挙げましょう。 APIを介してクラウドで仮想マシンを起動する場合、rootユーザーのメモリサイズ、CPUタイプ、オペレーティングシステム、SSHキーを指定できる必要があります。 仮想マシンごとに1時間あたりのインバウンドおよびアウトバウンドネットワークトラフィックを監視できる必要があります。 APIは、仮想マシンへのパブリックIPの割り当てとパブリックIPの取得をサポートする必要があります。 ... プロジェクトの後の段階で、クラウドAPIを標準化するいくつかのクラウドコンピューティング標準を分析して、現在の標準の潜在的な欠点がどこにあるかを見つけます。特定の標準はリソースの使用状況の監視をサポートしていないため、現在は使用できないという結果がおそらくあります。 現在、体系的に自分の要件を書き留めて分類する方法を模索しています。私が現在それらを書き留めている方法（上記の3つの点のように）はあまりにも非公式です。 私はいくつかの要件エンニーリングとソフトウェアアーキテクチャの本を読みましたが、それらはすべて詳細と実装に集中しすぎています。私は本当にAPI /インターフェースを介して提供される機能にのみ関心があり、UML図などは私にとって正しい選択だとは思いません。現在収集した要件はユーザーストーリーとして説明できると思いますが、高度な要件分析にはこれで十分ですか？たぶん私は「一段深く」行かなければならない...

8 documentation  api 

質問：一般向けのWeb API（HTTP Get / Postリクエストを送信し、JSON / XMLデータを取得する）の場合、スペルが間違っているか余分なパラメーターをどのように処理する必要がありますか？ 正しくないパラメーターが無視された場合、呼び出し元のコードのエラーは、有効な結果を返すため、気付かれないように思えます。これは、返された結果を見ても明らかではない状況で特に当てはまる可能性があります。 オプションのパラメーターのみを参照しています。明らかに、必須パラメーターのスペルが間違っている場合、パラメーターは欠落していると見なされ、エラーが返されます。 例として、Place Search API呼び出しには4つの必須パラメーター（位置、半径、センサー、キー）といくつかのオプションパラメーター（タイプはそのうちの1つ）があります。 これらのコマンドを（APIキーを使用して）実行し、有効な結果を取得できます。 curl "https://maps.googleapis.com/maps/api/place/search/json?location=45.47554,-122.794189&radius=500&sensor=false&key=<api_key>&type=bakery" curl "https://maps.googleapis.com/maps/api/place/search/json?location=45.47554,-122.794189&radius=500&sensor=false&key=<api_key>&types=bakery" 最初のコマンドには、「types」パラメーターが単数形であり、これは無効なキー名です。APIはそのパラメーターを無視し、すべてのタイプのエンティティを返します。この場合、エラーは明白ですが、発生しない場合（および他のAPI呼び出し）がある場合があります。

8 api  error-handling 

プログラミング言語で好きな構文と機能について話します。ここで、お気に入りの（または任意の）言語のライブラリで、コアとなる原則または機能についてお尋ねしますか？ 例として、リスト+ =リストエレメントのみを許可するのではなく、リスト+ = anotherListを追加することが有効です（ただし、これは悪い考えと見なされる場合もあります）。

8 design  libraries  api  interfaces 

私が取り組んでいるREST APIの場合、一貫したレイアウトでJSONを返したいです。 { "Data" : { "Id" : 123, "Email" : "charlie@somewhere.com" "Firstname" : "Charlie", "Surname" : "Brown", }, "Error" : null } ペイロードには常に「データ」と「エラー」が含まれ、どちらかがnullになる可能性があります。 私の質問は、「データ」と、実際には1つのオブジェクトしか返さないエンドポイントに関するものです。たとえばusers/current、現在認証されているユーザーを返すAPI があるとします。上記のようにそのユーザーを返したでしょう。「Data」という名前の単一のJSONオブジェクト。 ゼロ、1つ以上のオブジェクトを返す可能性のあるエンドポイントの場合、（もちろん） "Data"を配列にします。 { "Data" : [ { (first object) }, { (second object) } ], "Error" : null } 一貫性を保つために、「データ」は常に配列でなければならないという見方を聞いたことがあります。エンドポイントが論理的に1つのオブジェクト（またはnull）のみを返す場合でも。 他の人はどう思いますか？複数のオブジェクトが返されない場合は、「データ」と配列を作成する必要はないと思います。

8 api  rest  json