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

表現状態転送(REST)は、ネットワーキングソフトウェアがWeb経由で情報を転送するためのアーキテクチャスタイルです。

1
REST APIのリンクrel =“ self”のポイントは何ですか?
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 

3
ウィザードを使用したWebページのREST API設計
ウィザード形式のWebページがあります。APIへの送信ボタンは、ウィザードの4番目のステップにあります。ただし、ウィザードの次のステップに進む前に、入力したデータをデータベースに保存しておく必要があります。また、REST APIが単一のタブを持つページで機能するようにしたいと考えています。 そこで、クエリパラメータaction = draftまたはsubmitを実行するようにAPIを設計しました。アクションがドラフトの場合、特定のフィールドのみが必須です。アクションが送信の場合、すべてのフィールドが必須です。REST APIのサービスレイヤーでの検証は、クエリパラメーターに基づいて行われます。ドキュメントでif / else句を明示的に指定する必要があるようです。これはRESTfulな設計の受け入れ可能な形式ですか?これらの要件に最適な設計は何ですか?
11 design  rest 

2
多くのパラメーターを使用したREST 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コマースシナリオを考えてみてください。

3
symfonyで外部RESTful APIを利用する方法は?
私たちはプロジェクトのマイクロサービスアーキテクチャを構築しており、主にフロントエンドのSymfonyアプリケーションがバックエンドのRESTful APIと対話しています。 問題は、このアプローチがデータベースを持つDoctrineに大きく依存しているSymfonyエンティティ管理を壊していることです。Symfonyは通常、Doctrineでエンティティを処理し、ほとんどの作業を自動化しますが、APIから外部データにアクセスする必要がある場合、これは簡単に再現できません。 たとえば、クライアントエンティティの場合: Doctrineを使用すると、Clientクラスを定義するだけで、クライアントを簡単に作成、更新、取得できます REST APIアプローチを使用すると、APIを介してクライアントにアクセスできますが、クライアントの作成(POST)、更新(PUT)、取得(GET)などを定義するために多くの作業が必要です。 クライアントは、フロントエンドアプリだけでなく、専用のAPIだけでなく、いくつかのアプリケーションでも使用されています。 API呼び出しの複雑さを隠すエンティティのようなメソッドを使用してクラスを作成し、すべてのAPIデータをローカルにインポートして、Doctrineを通じて、または他の方法でそれらにアクセスする必要がありますか?

7
マイクロサービスアーキテクチャでは、サービスは互いに直接対話する必要がありますか?
Webアプリケーションを形成するWebサービスがいくつかあります。クライアントはREST API呼び出しを通じてこれらのサービスにアクセスできます。 これらのサービスは互いに直接通信できる必要がありますか?もしそうなら、それらはマイクロサービスの概念に反するカップルになるでしょうか? クライアントは、クライアントにWebページをロードするために必要なデータを取得するために、次々にそれらを直接呼び出す必要がありますか? または、クライアントからの要求を処理し、その要求のデータをフェッチしてからクライアントに送り返す、サービスの上に別のレイヤーを配置する必要がありますか?

3
HATEOASを使用してRESTサービスを発見するための戦略はありますか?
HATEOAS制約を使用してRESTサービスを構築する場合、リンクを介してリソースの存在を宣伝するのは非常に簡単です。あなたGETは私のサイトのルートにa を作成し、私はすべての第1層リソースをリストするルートドキュメントで応答します。 { users: { href: "/users" } questions { href: "/questions" } } これらのhref値の読み取り方法を理解しているクライアントは、これらの値に対してGET要求を実行し、アプリケーションで使用可能な現在のすべてのリソースを発見できます。 これは基本的なルックアップシナリオではうまく機能しますが、リソースがクエリ可能かどうかは示しません。たとえば、次のことを実行するのが妥当な場合があります。 GET /users?surname=Smith リソースの事前の知識がなくても、クライアントが一貫したクエリを形成できる十分な情報でこのクエリ機能を表現できる形式はありますか? さらに、クライアントがPOST期待された場所で特定の場所への実行を許可されていることを表現する方法はありますか。たとえば、クライアントが新しい質問リソースを作成するために以下を実行することが期待できます。 POST /questions { title: "Are there strategies for discovering REST services using HATEOAS?", body: "When building a REST service with the HATEOAS constraint, it's very..." } 人間が使用する形式としてHTMLを使用する場合、フォームとプロンプトを使用してこれを多く表現し、サービスで実行できる操作を人間が発見できるようにすることができます。 クライアントにとって同様のことができるフォーマットはありますか?
10 design  rest  hateoas 

1
非同期の内部通信を処理するためのベストプラクティス?
最近、クレジットカード処理を扱うプロジェクトを完了しました。私が直面した問題の1つは、通知メッセージの遅延/起こりうる失敗の処理でした。最も複雑な例は次のとおりです。 支払い要求を送信する外部システム 私のシステムはその要求を支払いゲートウェイへの要求に変えます ユーザーをゲートウェイに送信する ユーザーが支払いを実行するのを待っています ユーザーがシステムに戻ったが、システムが成功/失敗の通知を受け取るまで保留される 失敗に応じてユーザーを外部システムに送り返す さらに困難だったのは、通知の送信に失敗すると、ゲートウェイは15分ごとに何時間も通知を送信しようとすることでした。 保留中のトランザクションのデータベースレコードを使用して解決し、リターンからの成功と失敗に加えて、通知とトランザクション処理のための時限遅延リスナーを検出しました... かなり難しい! しかし、これは何億回も前に解決されたに違いないので、ベストプラクティスは何ですか? 私の将来は、これらすべてのシステム間の処理を記述し、時間遅延と起こりうるネットワーク障害を管理することになるので、ベストプラクティスに従いたいと思います。 本/記事の推奨事項は素晴らしいでしょう。 前もって感謝します!

2
RESTリソースが単数または複数であることは妥当ですか?
次のような従来のレイアウトではなく、私は疑問に思っています。 api/Products GET // gets product(s) by id PUT // updates product(s) by id DELETE // deletes (product(s) by id POST // creates product(s) たとえば、単数形と複数形の方が便利でしょう。 api/Product GET // gets a product by id PUT // updates a product by id DELETE // deletes a product by id POST // creates …
10 rest 

5
REST APIの概念
REST APIの設計について3つの質問があります。誰かに光を当ててもらいたいと思っています。私は何時間も執拗に検索しましたが、私の質問に対する答えがどこにも見つかりませんでした(たぶん、何を検索すればいいのか分かりませんか?)。 質問1 私の最初の質問は、アクション/ RPCに関するものです。しばらくREST APIを開発していて、コレクションやリソースの観点から物事を考えることに慣れています。しかし、私はパラダイムが適用されないように見えるいくつかのケースに遭遇し、これをRESTパラダイムと調整する方法があるかどうか疑問に思っています。 具体的には、リソースを変更するとメールが生成される場合があります。ただし、後で、ユーザーは以前に送信された電子メールを再送信することを具体的に示すことができます。電子メールを再送信しても、リソースは変更されません。状態は変更されません。発生する必要があるのは単にアクションです。アクションは特定のリソースタイプに関連付けられています。 ある種のアクション呼び出しをリソースURI(例:)と混合することは適切/collection/123?action=resendEmailですか?アクションを指定してそれにリソースIDを渡す方がよいでしょうか(例:)/collection/resendEmail?id=123?これはそれについて取り組むのに間違った方法ですか?従来(少なくともHTTPでは)実行されるアクションはリクエストメソッド(GET、POST、PUT、DELETE)ですが、これらは実際にはリソースを使用したカスタムアクションを許可していません。 質問2 URLのクエリ文字列部分を使用して、コレクションをクエリするときに返されるリソースのセットをフィルター処理します(例:)/collection?someField=someval。次に、APIコントローラー内で、そのフィールドと値とどのような比較を行うかを決定します。これは実際には機能しないことがわかりました。APIユーザーが実行する比較のタイプを指定できる方法が必要です。 私がこれまでに作ってみた最高のアイデアは、APIのユーザーはフィールド名(例えばへの付属物として、それを指定することができるようにすることです/collection?someField:gte=somevalどこでリソースを返す必要があることを示すために- someField何でも(> =)以上に等しいsomevalです。これは良いアイデアですか?悪いアイデアですか?そうであれば、なぜですか?指定されたフィールドと値で実行する比較のタイプをユーザーが指定できるようにするより良い方法はありますか? 質問3 s /person/123/dogsを取得するようなURIがよく見られます。最終的に私はそのようなURIを作成することで、実際には特定のIDでフィルターされたコレクションにアクセスしているだけだと考えているので、私は一般にそのようなものを避けました。これはと同等です。REST URIが2つ以上のレベル()になる正当な理由はありますか?persondogsdogsperson/dogs?person=123/collection/resource_id
10 api  rest 

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

4
REST APIは、日時を適切なクライアントのタイムゾーンに変換できる必要がありますか?
APIの実装中に、日時とタイムゾーンの問題が発生しました。 データベースでは、すべての日付がUTCに正規化されています。現在、非APIアプリケーションでは、すべての日時は、表示される前にまずユーザーの設定に基づいて変換されます。 APIについても同じ質問が浮上しました。APIは、要求のセマンティクスに基づいて、タイムゾーンに適した日時を返すことができる必要がありますか? 例えばGET /posts?timezone=America/Sao_Paulo? それとも、APIにアクセスしているクライアントで実行する必要がありますか? 更新:数回発生したため:現在、タイムゾーン付きのタイムスタンプが返されます(ただし、常にTZオフセットです+00:00)。形式は人気のある8601です。2015-10-29T23:00:49+00:00
10 rest  api  time 

6
RESTサーバーに対するRESTクライアントのテスト。フィクスチャーを行うには?
単体テストを作成するときは、フィクスチャを使用するのが一般的です。テスト可能なデータが少ないため、次のように言えます。1.すべてのクライアントにWilly Wonkaを含めます。2.クライアント3を削除し、クライアントにWilly Wonkaが含まれないようにします。 単体テストではそれで問題ありません。セットアップ/ティアダウンを使用して、フィクスチャを再ロードするか、トランザクションをロールバックします。したがって、テストの作成、更新、削除はトランザクション内で行われます。新しい一時データは、そのテストの間だけ保持され、その後リセットされます。 しかし、RESTサーバーをRESTクライアントから分離した場合はどうでしょうか。 RESTクライアントが正しく読み取っているだけでなく、正しく作成、更新、削除されていることを確認します。 リモートテストRESTサーバーに対してこれを行う方法の例や提案を見つけることができませんでした。 フィクスチャのみを提供するテストRESTサーバーがあるとします。HTTPの完全なステートレスの性質は、「BEGIN TRANSACTION」と「ROLLBACK TRANSACTION」または「RELOAD FIXTURES」タイプのメッセージを送信するのが難しいことを意味しますよね? 私はこれを最初にしたくないので、これについて別の考え方が必要だと感じています。 助言がありますか?
10 unit-testing  api  rest 

7
これは「アンチパターン」であり、使用を中止すべきですか、それともこの巧妙な設計ですか?
RESTサービスを作成するとき、私は基本的に次のことをするために凝視しました: HTMLが要求されています サービスは必要なWebページを返しますが、要求された「リソース」はありません。データ Webページには、同じサービス(異なるコンテンツタイプ)にAJAXリクエストを発行するJavaScriptが含まれています サービスが実際のデータ(JSON)を返し、ページに表示されます 一方では効率が悪いように見えます(2リクエスト)が、これを使用した場合、「パフォーマンスは問題ありません」、つまりトラフィックの少ない内部アプリとWebサイトはシンプルで高速にロードされます。 私がこれで終わった理由は、Webページがほとんど純粋なHtml + JavaScriptになる可能性があり、そのようなテーブルやものを作成するためにサーバー側のもの、特にループがほとんど必要ないことです(これは、 slickgridなど)、たとえばデータとビューの分離。 これを使用する前に、これは良いアイデアですか、それともやめるべきですか?

3
APIオブジェクトの定義にサードパーティの参照IDをプロパティとして含めるのは悪い習慣ですか?
このような: 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フィールドを許可することは、不適切な手法または不適切な設計と見なされますか?

3
疎結合のマイクロサービスアーキテクチャでは、依存関係をどのように追跡しますか?
最新のプログラムで人気のある高レベルのアーキテクチャの選択は、RESTベースのマイクロサービスシステムです。これには、疎結合、再利用の容易さ、使用できるテクノロジーの制限の制限、高いスケーラビリティなどのいくつかの利点があります。 しかし、そのようなアーキテクチャーで私が予測する問題の1つは、アプリケーションの依存関係が何であるかについての可視性が低いことです。たとえば、1組のREST呼び出しを毎日使用するアプリケーションがあるとします。このアプリケーションは、REST呼び出しの2番目のセットも使用しますが、四半期に1回だけです。過去1週間のログをスキャンすると、1日のカロリーはすべて表示されますが、四半期ごとの呼び出しは表示されません。リファクタリングの時期になると、四半期ごとの呼び出しが中断するリスクが高くなります。 このリスクを軽減し、疎結合アーキテクチャの依存関係をより詳細に可視化するために使用できるパターンまたはツールは何ですか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.