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

データソースの上にビジネスロジックを追加するWebサービスがあるとします。このサービスの各APIはほとんどのように見えます-一連の制約が与えられた場合、これらの制約を満たすデータソースからのアイテムを提供します。APIからデータソースの「ビュー」を取得したと言えます。 ここで、時間の経過とともに、データソースに対してさまざまな種類のビューを返すように求められます。「十分に異なる」ビューごとに新しいAPIを追加するか、ギアを切り替えて、目的のビューの種類を指定するパラメーターを取得するgetFooDataView（）APIを提供するオプションがあります。どちらの方法に行くかを決定するために、いくつかの競争圧力があります。 あなたのサービスの既存の大きなクライアントは怠惰であることを好み、データの新しいビューが必要なときに新しいAPIまでコーディングする必要はありません。 ただし、一部のリクエストパラメータ（制約）は一部のビューでのみ意味があり、他のビューでは意味がありません。「XYZビューが必要な場合は、 "foo"パラメータを設定すると、APIコントラクトを緩くする必要があります。一部のビューではそうであるとしても、 "foo"を必須パラメーターにすることができないという残念な副作用があります。 新しいクライアントがサービスを活用したいというケースはますます増えています。どちらがより混乱するかを決定することはできません-異なるがより厳密に定義されたAPIと、パラメーターのどの組み合わせが本当に必要なものを提供するかを知る必要がある1つのAPIを選択する必要があります。 これを抽出するために、既存のAPIのバリエーションとは対照的に、何かが独自のAPIである必要があるという線を描くのはいつですか？2人のクライアントの要求を意味的に区別する理由については、協力しなければならない人によって見方が異なるため、この問題についてコンセンサスを得るのは難しい場合があります。また、将来のクライアントがサービスを利用するのが極端に難しくならないようにする必要もあります。この種の選択を行うためのいくつかのベストプラクティスは何ですか？

8 design  design-patterns  web-services  api-design  usability 

私はAndroidを使い始めActivityたばかりで、状態をバンドルに保存するチュートリアルを行っているときに、より一般的なListインターフェースを受け入れる代わりに、Bundleputメソッドが期待していることに気付きましたArrayLists。 例： Bundle.putCharSequenceArrayList(key, value) Bundle.putIntegerArrayList(key, value) Bundle.putParcelableArrayList(key, value) Bundle.putStringArrayList(key, value) 私たちのほとんどは、オブジェクトがインターフェイスによって参照される必要があることを示唆している効果的なJavaの項目52に精通しているので、このAPI決定の背後にある理由は何だったのかと思います。 あるArrayListおそらくアンドロイドの優先リストの実装？

8 java  android  api-design  android-development 

私が取り組んでいるプロジェクトでは、ウィジェットに関するメッセージをメッセージキューを介して送信し、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 

HATEOAS APIでは、可能な状態遷移を表すリンクが返されます。適合クライアントはそれらのリンクを取得してたどるだけですが、不適合クライアントが提供されたリンクをたどるのではなくURIを構築している場合、返される最も適切なステータスコード/応答は何でしょうか？ 400は、応答本文のいくつかの情報と一緒に機能します-これは私たちが現在行っていることです 403リクエストが機能しない可能性があることを意味するため、間違っていると思いますが、将来的にリンクが使用可能になる可能性があります 404はもっともらしいようです-この時点ではリソースは存在しません 人々はどう思いますか？条件付き要求は古い応答（結果として412sなど）に基づいて要求を処理できることを知っていますが、これは少し異なる状況です。 更新： これらのタイプの無効な操作に対する正しい応答は404であることがわかりました。リクエストの構文が正しい場合、有効なリソースに送られますが、ビジネスルールに違反しています。次に、いくつかの不自然な例を示します。 クライアントが、互いに20％以内でなければならない2つの数値を提供できるとしましょう。 クライアントがいくつかの計算を経た数値を提供できるとしましょう。その結果は、提供された元の数値が正しくなかったことを示しています。 400はこれらの正しい応答ですか？

8 rest  api-design  hateoas