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

C＃ではstring、別のものstringを分割したい場合は、そのようなことをしなければなりません： testString.Split(new string[] { "anotherString" }, StringSplitOptions.None); オーバーロードされたString.SplitMSDNドキュメントから、実装とそのような呼び出しを行う必要がある理由を確認できます。 Pythonから来たので、なぜこのような呼び出しが必要なのかを正しく理解するのは難しいです。Regex.SplitPythonの実装と同様の構文を取得するために使用できましたが、単純なものではパフォーマンス（セットアップ時間）が低下するという犠牲を払う必要があります。 だから基本的に、私の質問は、なぜ地獄ができないのかということです： testString.Split("anotherString"); プロトタイプも実装も提案していないことに注意してください。現在のAPIを考慮して上記のバージョンを実装できない理由を理解しています。私の目標は、上記の構文がもたらす利点を考慮して、そのようなAPIが作成された理由を理解することでした。今のところ、柔軟性はString.Split理にかなった現在の目標のようですが、正直なところ、どこかで何らかのパフォーマンスの向上があると本当に思っていました。私は間違っていたと思います。

11 c#  performance  api-design 

SOAPベースのサービスのセットをRESTful APIに変換しようとしています。 オペレーション名を分析してリソースを識別することから始め、リソースを取得しましたSubscription。 サブスクリプションの状態を更新する必要がある場合POST、リソースに直接アクセスできないため、サーバーに単純に要求を送信することはできませんが、RPCスタイルの操作を呼び出してプロパティを更新する必要があります。さらに、サブスクリプションの状態を「アクティブ」に変更する場合にのみ、外部サービスへの追加の呼び出しが必要です。 これらの場合、基礎となる操作を処理するためのベストプラクティスは何ですか？ 私が思いついた解決策は、クエリパラメータを使用することです。そのため、アクティベーションサービスを呼び出す必要がある場合は、次のようなものを使用できます。 POST /subscriptions/{subscriptionid}/?activate=true Subscriptionオブジェクトのフィールドを直接更新できないことを考えると、この種の変換を処理するベストプラクティスはありますか？ 更新1： POSTリクエストの本文にいくつかの値、たとえば「state」：「active」を入れることができます サービス内でトリガーされる適切な操作を確認します。

11 rest  web-services  api-design  web-api 

たとえば、クライアント、レポートなどのエンティティがあります。クライアントには多くのレポートがある可能性があり、単一のレポート管理のエンドポイントは次のようにネストする必要があると思います。 /clients/{client_id}/reports/{report_id} 1つのクライアントのすべてのレポートに関しては、エンドポイントが期待されます。 /clients/{client_id}/reports しかし、すべてのクライアントのすべてのレポートを取得して、APIの一貫性と適切な設計を維持するためのエンドポイントをどのように見ればよいか 私のアプローチ： （私はそれをいくつかのgoogle apiで見ました）それの代わりに「-」を使用し、それを「すべて」として解析します： /clients/-/reports これはエンドポイントのフォーマットを同じに保ちますが、少し変わって見え、この方法を示唆するrfcを見つけることができません。 すべてのレポートのためだけに別のエンドポイントを作成します。 /reports ただし、クライアントのレポートを取得するには、次のようにします。 /clients/{client_id}/reports エンドポイントをリファクタリングして、「クライアント」を親ではなく、単なるフィルタパラメータにします。 /reports?client={client_id} -1つのクライアントのレポート /reports -すべてのクライアントのレポート 特定のクライアントのレポートを投稿するための新しいエンドポイントを追加する場合、URLにパラメーターを持つPOSTリクエストになるため、見栄えが悪くなる可能性があります。 他にアイデアの提案はありますか？

11 rest  api  api-design 

さまざまなプログラムからのアラートメッセージを処理し、それらのアラートを処理して電子メールを介してダウンコンシューマーに送信できるシステムを作成したいと考えています。これはすべて1つの内部ネットワークに含まれます。 基本的なアーキテクチャを次のようにしたいと思います。 私の現在の主な関心事は「メッセージハンドラー」ビットです。これが私の「ソートAPI」になります。このシステムのすべてのコンポーネントが、データベースへのすべての書き込みを処理するAPIにデータを送信するようにします。このアプローチは、セキュリティを簡素化し、より複雑なDBクエリの多くを1つのプログラムに含めることができるため、より簡単だと思います。 懸念事項は、これを言語にとらわれないようにしたいことです。つまり、どのコードでもメッセージをハンドラに送信して、メッセージを解釈できるようにする必要があります。これは、JSONフラットファイルを介して、またはプログラムへのREST呼び出しを介して（下流のアプリケーションに柔軟性を与える）希望します。 私の質問は メッセージハンドラーを気にする必要がありますか？それとも、下流のアプリケーションと他の2つのコンポーネント（管理コンソールとアラートマネージャー）への直接データベースアクセスを許可するだけで簡単になりますか？ このようにして、DBテーブルへのINSERTが有効である限り、任意のアラートを挿入できます。 私は貿易でソフトウェアデザイナーではないので、失礼します。ただ、自由な時間にプロジェクトをやってもらいたいのです。

10 design  design-patterns  architecture  api  api-design 

Java 7の「Project Coin」に提案された機能の1つは「Elvisオペレーター」でした。2009年のJavaOneプレゼンテーションのレポートプロジェクトコインには、そのように説明しました。 このプレゼンテーションで取り上げられている「小さな機能」の1つは、いわゆる「エルビス演算子」です。これは、3項演算子のより簡潔なバージョンです。伝統的なJavaを使用すると、Groovyの一部の機能が欠けていることに気づきました。これは、追加された場合、両方の言語で使用できる1つの演算子になります。「Elvis」演算子は、評価された式がnullのときに使用できるデフォルト値を指定するのに便利です。Groovyの安全なナビゲーション演算子と同様に、これは不要なnullを回避する方法を指定する簡潔な方法です。NullPointerExceptionを回避する方法については、以前ブログで説明しました。 プロジェクトコインの他の側面は最終的に実装されましたが、これは実装されませんでした。含まれる可能性のある候補としてJavaOneで提示されたにもかかわらず、Elvisオペレーターが最終的に拒否されたのはなぜですか？ 明確にするために、私はこのオペレーターについて具体的に尋ねています。このオペレーターが当時真剣に検討されていたため、Java 7の「プロジェクトコイン」の一部として拒否された理由についてです。メーリングリストなどで拒否の理由が議論されているのではないかと思いますが、何も見つかりませんでした。Javaのどのバージョンにも含まれていない理由に関するより一般的な情報がある場合、それは許容されますが、好ましくありません。

10 java  api-design 

外部の開発者が使用している商用ライブラリとコード例を作成します。ライブラリの使用方法を広範囲に説明する（登録済みユーザーは利用できますが、閉鎖された）ドキュメントがあります。 開発者の多くは初めてのユーザーなので、多くの初歩的なエラーが発生します。 エラーログにドキュメントへのリンクを含めることは適切ですか？考えられる欠点は何ですか？いくつかは予想できますが、以下を克服することは可能と思われます ドキュメントのURLが古い 最新のドキュメントに反映されていないバージョン固有のエラー 他に何か問題があり、無関係なドキュメントに送信することで開発者の時間を無駄にしています 意味の例の下に、太字のテキストを追加するのは良い考えですか？ [エラー]プロジェクトstandalone-pomで目標org.apache.maven.plugins：maven-archetype-plugin：1.2.3：generate（default-cli）を実行できませんでした：目的のアーキタイプが存在しません（com.example.library。 archetypes：library-archetype-blank：1.2.3.0）->詳細および考えられるトラブルシューティングについては、http：//example.com/docs/setting-up-an-archetypeを参照してください

10 documentation  api-design  error-handling  error-messages 

私はJavaが初めてで、例外に関するドキュメントを読んでいました。、特にチェックされていない例外—論争のページ。 一番下の行は言う： クライアントが例外からの回復が合理的に期待できる場合は、チェック済み例外にします。クライアントが例外から回復するために何もできない場合は、チェックされていない例外にします。 記事がわかりません。「論争」とは何ですか？簡単な言葉で説明できますか？

10 java  api-design  exceptions 

API /パブリックメソッドシグネチャへの変更は、これらのメソッドを使用するクライアントコードを壊さないようにするために最小限でなければならないので、デメテルの法則はこれらにあまり適用されないのではないかと思っていました。 簡単な例： class Account() { double balance; public void debit(Transaction t) { balance -= t.getAmount(); } } debitメソッドは、2倍の金額ではなくTransactionオブジェクトを渡すことに注意してください（ 'Law of Demeter'は、私が理解しているように、必要な情報だけを渡すと言います。この場合、Transactionオブジェクトではなく、金額だけを渡します... ）。この背後にある理由は、将来のメソッドでは、金額の他にいくつかのトランザクションプロパティが必要になる可能性があるためです。私が理解していることから、これは将来的に新しいパラメータを追加することによってメソッドのシグネチャを壊すことを防ぎます。 これはそれを賢明な選択にしますか？それとも何か不足していますか？

10 design  api-design 

私は次のエンドポイントを持っています： a/{id}/b b送信POSTリクエストを含むを作成します。もしa与えられたもの{id}が見つからない場合、私は、404 NOT_FOUNDまたは多分で応答すべき409 CONFLICTですか？ それはplainを処理することでありa/{id}、トリックはここでサブリソースが使用されることです。

10 rest  api  api-design  http-request 

「ウィジェット」、つまりパートナーがWebサイトに埋め込んで、UIを表示し、APIを呼び出すスクリプトを設計する必要があります。 基本的に、API呼び出しで提供するいくつかのIDに基づいて、これらのサイトのデータを表示します。回避したいのは、誰かがAPIを悪用し、それを使用してカタログ全体をこすり取ることです。 スクリプトを埋め込む各パートナーには、APIを呼び出すときに提供する必要がある公開鍵が与えられます。スクリプトをロードするときに、このキーを追加するように依頼することをお勧めします。例： <script src="//initrode.com/widget/loader.js?key=xxxx"></script> このようにして、スクリプトのリクエストを使用してキー/ソースIPペアを登録し、キー/ IPペアが登録されたものと一致する場合に限り、後続のAPI呼び出しに応答できます（ライフタイムが制限され、1日あたりのリクエスト数に制限があります）。 それは明らかに難読化によるセキュリティです（スクリプトを再読み込みすると完全にバイパスされます）。しかし、アクセスを制限する他の方法はありません。すべてのユーザーに一意のキーを提供することはできません。パートナーにのみ提供します。すべてのコードが誰でも利用できるようになるため、私は秘密鍵システムを使用できません。基本的に、パブリックAPIへのアクセスを制限しています。つまり、その定義が矛盾しています。 このソリューションについてどう思いますか、これらの制約をどうしますか？

10 security  api-design  web-api 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 C API（標準ライブラリ、サードパーティのライブラリ、プロジェクト内のヘッダーなど）の問題を引き起こす欠陥は何ですか？目標は、CでのAPI設計の落とし穴を特定することです。これにより、新しいCライブラリを作成するユーザーは、過去の過ちから学ぶことができます。 欠陥が悪い理由を説明し（できれば例を挙げて）、改善策を提案してください。あなたの解決策は実際には実用的ではないかもしれませんが（修正するには遅すぎますstrncpy）、将来のライブラリライターのために準備を整える必要があります。 この質問の焦点はC APIですが、他の言語でそれらを使用する能力に影響を与える問題は大歓迎です。 民主主義が回答を分類できるように、回答ごとに1つの欠陥を指定してください。

10 c  api-design  pitfalls 

ユーザー入力を解析する場合、例外をスローしてキャッチするのではなく、検証メソッドを使用することをお勧めします。.NET BCLでは、これは、たとえばint.Parse（無効なデータで例外をスローする）とint.TryParse（false無効なデータで戻る）の違いになります。 私は自分でデザインしています Foo.TryParse(string s, out Foo result) メソッドと私は戻り値がわからない。bool.NET独自のTryParseメソッドのように使用することもできますが、エラーのタイプ、つまりに解析できなかった正確な理由について sはわかりませんFoo。（たとえば、s括弧Barが一致していない、文字数が間違っている、対応するがないBazなど） APIのユーザーとして、操作が失敗した理由を通知せずに成功/失敗のブール値を返すだけのメソッドは嫌いです。これにより、推測ゲームのデバッグが可能になり、ライブラリのクライアントにもそれを課したくありません。 私はこの問題の多くの回避策（ステータスコードを返す、エラー文字列を返す、エラーパラメータを出力パラメーターとして追加する）を考えることができますが、それぞれに欠点があり、また、 .NET Frameworkの。 したがって、私の質問は次のとおりです。 （a）例外をスローせずに入力を解析し、（b）単純なtrue / falseブール値よりも詳細なエラー情報を返す.NET Frameworkのメソッドはありますか？

9 c#  .net  api-design 

このような： Campaign: type: object properties: id: type: string description: "A GUID identifier" referenceId: type: string description: "A consumers identifier they have used to map their own systems logic to this object." name: type: string description: "'Great Campaign 2017' as an example" referenceIdが心配です。 システムドメインは、さまざまな形式（xml、excel）のデータのエクスポートおよびインポートを通じて、サードパーティと多くの方法で統合されるプラットフォームです。サードパーティがAPIを介してシステムと統合できるように十分に成熟しており、このAPIの設計がこの疑問を引き起こします。 リソースを識別して取得するために使用できるIDを持つオブジェクト、キャンペーンがあります。APIの利用者は、ドメイン内のキャンペーンと見なすものへの独自の参照コードを持っている場合があります。 私たちのシステムには、このようなサードパーティの参照フィールドを持つ他のオブジェクトがあり、既存のコンシューマーから期待されています。ただし、マッピングの負担がかかり、このreferenceIdが何であるか（数値、テキスト、json？）がわからないため、新しいコンシューマー向けの混乱するプロパティがAPIに追加されます。 APIのパブリックオブジェクト定義でサードパーティの参照IDフィールドを許可することは、不適切な手法または不適切な設計と見なされますか？

9 rest  api  domain-driven-design  api-design  single-responsibility 

次の応答モデルを吐き出すHTTP APIエンドポイントを取ります。 { "type": "Dog", "name": "Jessi", ... } typeフィールドは次のいずれかであるとしてドキュメントに記載されているDog、CatまたはFish。 新しいオプションの追加は、たとえばRat、重大なAPIの変更と見なされますか？ 有限リスト（開発者がオンにする可能性がある）にオプションを追加することは、APIの拡張または変更と見なされますか？

9 rest  api  api-design  json 

RESTについての理解は、サービス操作を状態の表現としてモデリングし、HTTPを使用してある状態から別の状態に遷移することを可能にします。リソースをサービスサイドの状態の表現として常に理解してきました。最近まで、コミュニティから尊敬されている賢い開発者/アーキテクトであることがわかっているJimmy Bogardによるこの記事を読みました。その投稿から特定のステートメントを引用するには 表現は少し異なります- リソースの現在の状態を示します（要求されたとき）。 これは私を混乱させました。このトピックについて一般的に受け入れられている意見は何ですか？

9 rest  api  api-design