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

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 編集：あなたがodataに精通していない場合、ここに行きます。 この技術を学ぶ価値があるのか​​、それが理解できないものなのかを判断しようとしています。 前提は興味深いものであり、APIの開発者としては、APIを使用する開発者により多くの柔軟性を提供する良い方法のようです。 残念ながら、過去数年間、Open Data Protocolに関する「バズ」はあまり見られないので、一度習得したら、その可能性があるかどうかを測定しようとしています。 前もって感謝します。

12 api  web-api  standardization 

ハイフン（ケバブケース）を使用するJSONキーへのアクセスに関する多くの質問が表示されますが、今ではキーにキャメルケースまたはsnake_caseを使用するべきかどうか疑問に思っています。言語間で移植すると、ハイフンが複雑なマッピングを作成することもあります。一部のJSONデシリアライズライブラリがこれらのキーをcamelCaseスタイルに変換するのを見てきました。 例： var something = { "some-value": 'thing' } 対 var something = { "someValue": 'thing', "some_other_value": 'thing_two' }

12 javascript  api  api-design  json  web-api 

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

11 rest  web-services  api-design  web-api 

HTMLドキュメントで以下をよく見ます <link rel="self" href="http://example.com/something"> またはJSONでこれのように link: { rel="self", href="http://example.com/something" } またはXMLで <atom:link rel="self" href="http://example.com/something" /> だから私はいくつかの質問がありました： なぜこのリンクを含めるのですか？それはどのような利点をもたらしますか？（それには理由があり、それは単なる「良い習慣」のお守りではないことを教えてください） このリンクをクライアントでどのように活用すればよいですか？このリンクの使用例は何ですか？ このリンクを使用すべきでないのはいつですか？それを含めるのはいつ無意味ですか？

11 rest  web-api 

パラメーターの（長い）リスト（たとえば、8つのパラメーター）を受け取るGET操作を備えたREST APIがあります。この操作の目的は、要素を検索してフィルタリングすることです。 このシナリオを管理するためのベストプラクティスはどれですか。： （1）パラメータのリストを受け取りますか？： public ResultType Get(int p1, int p2, string p3...) { ... } （2）または、これらのパラメーターをカプセル化するオブジェクトを受け取りますか？： public class MyClass { public int X { get; set; } public int Y { get; set; } public string Z { get; set; } } public ResultType Get(MyClass parameter) { ... } 名前、説明、カテゴリ、ブランド、モデル、価格などで「製品」を検索およびフィルタリングするeコマースシナリオを考えてみてください。

11 rest  patterns-and-practices  web-api 

「ウィジェット」、つまりパートナーが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 

REST APIの作成を進めており、現在、次の問題が発生しています。 Foo最初のリソースです。CRUD操作は/foo/URI を介して適用できます。 Bar2番目のリソースです。CRUD操作は/bar/URI を介して適用できます。 Every Fooは0または1に関連付けられていますBar。のBarサブリソースとして扱わないのFooはBar、複数Fooのs 間で同じインスタンスを共有できるためです。ですから、の代わりに独立したURI経由でアクセスする方がよいと考えました/foo/[id]/bar。 私の問題は、かなりの場合、インスタンスを要求するクライアントがFoo関連するインスタンスにも関心があることBarです。現在、これは、1つではなく2つのクエリを実行する必要があることを意味します。1つのクエリで両方のオブジェクトを取得できる方法を紹介したいのですが、そのためのAPIをモデル化する方法がわかりません。これまでに思いついたこと： 次のようなクエリパラメータを導入できます/foo/[id]?include_bar=true。このアプローチの問題は、応答のリソース表現（JSON構造など）が異なるように見える必要がある（たとえば、{ foo: ..., bar: ... }単にシリアライズされたものではなく、コンテナーなどFoo）ため、Fooリソースエンドポイントが「異種」になることです。それは良いことではないと思います。をクエリする場合/foo、クライアントはクエリパラメータに関係なく、常に同じリソース表現（構造）を取得する必要があります。 もう1つのアイデアは、新しい読み取り専用エンドポイントを導入すること/fooandbar/[foo-id]です。この場合、のような表現を返すことは問題ありません。これ{ foo: ..., bar: ... }は、fooandbarリソースの「公式」表現にすぎないためです。ただし、そのようなヘルパーエンドポイントが本当にRESTfulであるかどうかはわかりません（これが質問のタイトルに「can」と書いた理由です。もちろん、技術的には可能ですが、それが良いアイデアかどうかはわかりません）。 どう思いますか？他の可能性はありますか？

9 rest  web-api  resources 

私のWebアプリケーションの設計について深刻な疑いがあります。 ビジネスロジックをインターフェイスから分離したかったので、データベースへのすべての要求を処理するWeb APIを作成しました。 これは、エンティティフレームワークと作業ユニットおよび汎用リポジトリパターンを備えたASP.NET Web APIです。これまでのところ、すべてが良好です。 問題 ヘルプが必要なのは、APIとアプリケーションの間でオブジェクトを共有する効率的な方法がわからない場合です。 エンティティオブジェクトを直接シリアル化したくありません。エンティティモデルが変更された場合、理由もなく大きなオブジェクトをシリアル化してしまう可能性があるため、これは悪い習慣だと思いました。 現在どのように実装されているか インターフェイスはC＃のASP.NET Webアプリケーションであり、APIはC＃であるため、共有したいすべてのクラスの定義を含む共通ライブラリを作成しました。 私はAndroidアプリを開発するときにソリューションが機能しないことを知っています。Javaでクラスを再度作成する必要がありますが、それは私の最大の問題ではありません。 問題は、常にオブジェクトを変換しているような気がすることです。 例 これが私のワークフローの例です： すべてのオブジェクトとフォームのデータ注釈を含むモデルから始め、ユーザーはそのモデルをコントローラーにPOSTします。 コントローラーでは、このモデルを共通ライブラリーのクラスに変換してから、そのオブジェクトをAPIに送信する必要があります。 次に、私のAPIのコントローラーが呼び出しをキャッチし、そのオブジェクトをエンティティオブジェクトに変換して、データベースを更新します。 だから私は3つのクラスを持っています 検証用のすべてのデータ注釈を含むビューのモデル（クライアント） オブジェクトを共有するための共通ライブラリクラス（DLL） エンティティークラス（API） 何か間違ったことをしているような気がします。よりエレガントなものはありますか？プロジェクトが大きくなりすぎる前に、この問題に対する適切な解決策があることを確認したいと思います。

9 design  design-patterns  web-development  web-api