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

私のREST実装は、次の構造を持つJSONでエラーを返します。 { "http_response":400, "dev_message":"There is a problem", "message_for_user":"Bad request", "some_internal_error_code":12345 } プロパティ（dev_message、message_for_user、some_internal_error_code）に必要な値を渡し、それらを返すことができる特別な応答モデルを作成することをお勧めします。コードでは、これは次のようになります。 $responseModel = new MyResponseModel(400,"Something is bad", etc...); このモデルはどのように見えるべきですか？メソッドを実装する必要があります。たとえば、テキスト情報のみを渡すsuccessResponse（）で、コードはデフォルトで200になりますか？これにこだわっています。これは私の質問の最初の部分です。このモデルを実装する必要がありますか、これは良い練習ですか？今のところ、コードから直接配列を返すだけだからです。 2番目の部分は、エラーコードシステムについてです。エラーコードについては、ドキュメントで説明します。しかし、私が遭遇している問題はコードにあります。エラーコードを管理する最良の方法は何ですか？それらをモデル内に記述する必要がありますか？または、これを処理するための別のサービスを作成する方が良いでしょうか？ 更新1 応答用のモデルクラスを実装しました。これはGregの答えと似ていますが、同じロジックですが、さらに、モデルに記述されたエラーをハードコーディングしました。ここでは、次のようになります。 class ErrorResponse { const SOME_ENTITY_NOT_FOUND = 100; protected $errorMessages = [100 => ["error_message" => "That entity doesn't exist!"]]; ...some code... } なぜこれをしたのですか？そして何のために？ コードでは格好いいです： return new ErrorResponse(ErrorResponse::SOME_ENTITY_NOT_FOUND ); …

15 php  mvc  rest  api 

私は現在、Cで書かれたライブラリに取り組んでいます。このライブラリの多くの関数は、引数として、char*またはconst char*引数に文字列が必要です。私は、文字列の長さを常に期待しているsize_tので、ヌル終端が必要ないようにそれらの関数から始めました。ただし、テストを作成する場合strlen()、次のようにが頻繁に使用されます。 const char* string = "Ugh, strlen is tedious"; libFunction(string, strlen(string)); 適切に終了した文字列を渡すようにユーザーを信頼すると、安全性は低下しますが、より簡潔で（私の意見では）読み取り可能なコードになります。 libFunction("I hope there's a null-terminator there!"); だから、ここで賢明な慣行は何ですか？APIの使用をより複雑にしますが、ユーザーに入力を考えさせるか、ヌル終了文字列の要件を文書化し、呼び出し元を信頼しますか？

15 c  api  strings 

マイクロサービスアーキテクチャに関する多くの記事を読みましたが、AMQPまたはRESTをいつ使用すべきか疑問に思いました。 サービス間の疎結合は良いことであり、その場合AMQPが良い選択であるように思えます。しかし、AMQPを使用する場合、これはRESTエンドポイントが不要になることを意味します（ただし、HATEOASコンセプトが失われることを意味します）。 しかし、RESTは本当に私のサービスを構築するのに良い方法ですか？原因エンドポイントを使用しません...この場合、一方が他方より優れていますか？ いつどちらを使用すればよいですか？

15 rest  api  web-services  microservices 

私は、開発中のAPIクライアントライブラリを単体テストするための最良の方法を見つけようとして、一周して回りました。このライブラリには、Client基本的にAPIとの1：1マッピングを持つWrapperクラスと、の上部でよりユーザーフレンドリーなインターフェイスを提供する追加のクラスがありますClient。 Wrapper --> Client --> External API 私は最初の両方に対してテストの束を書いたClientし、Wrapper効果的にちょうど彼らが前方（上で動作するものは何でもの適切な機能にそのことをテストし、Wrapper上の動作Client、およびClientHTTP接続で動作します）。しかし、インターフェイスではなくこれらのクラスの実装をテストしているように感じるので、これに不快感を覚え始めました。理論的には、クラスを別の完全に有効な実装に変更することはできましたが、呼び出されると予想されていた関数が呼び出されていないため、テストは失敗します。それは私にとって脆弱なテストのように聞こえます。 この後、クラスのインターフェースについて考えました。テストでは、クラスが実際に行う方法ではなく、クラスが実際に意図したジョブを実行することを確認する必要があります。どうすればこれを行うことができますか？最初に頭に浮かぶのは、外部APIリクエストをスタブ化することです。しかし、私は外部サービスを単純​​化しすぎることに神経質です。私が見たスタブAPIの例の多くは、定型応答を提供しているだけです。これは、コードが偽のAPIに対して正しく実行されることをテストするだけの非常に簡単な方法のようです。別の方法はサービスをモックすることです。これは実行不可能であり、実際のサービスが変更されるたびに最新の状態に維持する必要があります。 最後に、私はこれを に、プログラマーSEに関する別の回答ました。 リモートAPIクライアントの仕事は、特定の呼び出しを発行することです-これ以上でもそれ以下でもありません。したがって、そのテストでは、これらの呼び出しを発行することを確認する必要があります-これ以上でもそれ以下でもありません。 そして今、私は多かれ少なかれ確信しています-テストするとき、テストClientする必要があるのは、APIへの正しいリクエストを行うことだけです（もちろん、APIが変更される可能性は常にありますが、私のテストは合格し続けます-しかしそれは統合テストが役立つ場合）。以来Clientちょうど1：APIと1のマッピング、私の懸念は実際には適用されません別の有効な実装から変更について前に-の各メソッドの唯一の有効な実装がありますClient。 しかし、私はまだにこだわっています Wrapperクラスにます。次のオプションが表示されます。 Clientクラスをスタブ化し、適切なメソッドが呼び出されることをテストします。このように、私は上記と同じClientことをしていますが、APIの代用として扱います。これは私が始めたところに私をすぐに戻します。繰り返しになりますが、これはインターフェースではなく実装のテストの不快感を与えてくれます。のWrapper非常によく、完全に別のクライアントを使用して実施することができます。 モックを作成しますClient。ここで、モックを作成する方法を決定する必要があります。サービスの完全なモックを作成するには、多くの労力が必要になります（ライブラリ自体に行った以上の作業）。API自体はシンプルですが、サービスは非常に複雑です（基本的に、そのデータに対する操作を備えたデータストアです）。そして再び、私は私のモックを本物と同期させておく必要がありますClientます。 適切なHTTPリクエストが行われていることをテストするだけです。これはWrapper、実際のClientそれらのHTTP要求を行うためにオブジェクトをため、実際に個別にテストするわけではありません。これは少しひどい単体テストになります。 したがって、これらのソリューションのいずれにも特に満足していません。あなたならどうしますか？これについて正しい方法はありますか？

14 unit-testing  testing  api  mocking  adapter 

現時点でAPIに取り組んでおり、APIキーを送信するのに最適な場所がどこにあるべきかについて意見を収集したかっただけです。URLに入れるべきではないことを知っています。これにより、リクエストヘッダーまたはメッセージ本文が残ります。 それをヘッダーに入れると、すべてのサービスで使用できる一般的なメソッドを引き出すことができますが、私が渡された仕様はそれを本体に必要としています（つまり、JSON文字列でPOST本体のシリアル化されたオブジェクト）。

14 api 

私はサービスのREST APIを設計しており、リソースをネストする適切な方法にこだわっています。 リソース：パートナー、チケット、設定 リソース間の接続： パートナーには多くのチケットがあり、 パートナーは設定のセットを持っています、 Bussinesロジック： すべてのパートナーを匿名ユーザーとしてリストできます。 指定したパートナーに匿名ユーザーとして新しいチケットを追加できます。 パートナーのみが自分のチケットをリストできます。 パートナーのみがチケットを変更できます。 パートナーのみが設定を一覧表示できますが、 パートナーのみが設定を変更できますが、 私が今までやったこと： パートナーリソース GET / partners-すべてのパートナーを一覧 表示 GET / partners /：id- ：idパラメーターで指定されたパートナーの詳細を表示GET / partners /：partner_id / tickets-パートナーのチケットの一覧 GET / partners /：partner_id / tickets /：id-詳細指定されたパートナーのチケットの POST / partners /：partner_id / tickets-新しいチケット PUTを保存する/ partners /：partner_id / tickets /：id-：idパラメーターで指定されたチケットを更新する GET / …

14 api  rest  api-design 

スーはJavaScriptライブラリを設計していますMagician.js。その要はRabbit、渡された引数から抜き取る関数です。 彼女は、そのユーザーがウサギを引き出したいことを知っているString、Number、Function、多分HTMLElement。それを念頭に置いて、彼女は次のようにAPIを設計できます。 厳格なインターフェース Magician.pullRabbitOutOfString = function(str) //... Magician.pullRabbitOutOfHTMLElement = function(htmlEl) //... 上記の例の各関数は、関数名/パラメーター名で指定された型の引数を処理する方法を知っています。 または、彼女はそれを次のように設計できます： 「アドホック」インターフェース Magician.pullRabbit = function(anything) //... pullRabbitanything引数が想定されるさまざまな異なるタイプ、および（もちろん）予期しないタイプを考慮する必要があります。 Magician.pullRabbit = function(anything) { if (anything === undefined) { return new Rabbit(); // out of thin air } else if (isString(anything)) { // more } else if (isNumber(anything)) { // more …

14 javascript  api  api-design 

私はWebSQL / Phonegap Database APIのクエリ抽象化をいじっていますが、自然な英語の文法の使用を模倣する流なAPIを定義することに惹かれ、疑っています。 これを例で説明するのが最も簡単かもしれません。以下は私の文法におけるすべての有効なクエリであり、コメントは意図したセマンティックを説明しています： //find user where name equals "foo" or email starts with "foo@" find("user").where("name").equals("foo").and("email").startsWith("foo@") //find user where name equals "foo" or "bar" find("user").where("name").equals("foo").or("bar"); //find user where name equals "foo" or ends with "bar" find("user").where("name").equals("foo").or().endsWith("bar"); //find user where name equals or ends with "foo" find("user").where("name").equals().or().endsWith("foo"); //find user …

14 javascript  api 

ベンダーのAPIを使用していると仮定して、APIが期待どおりに機能することを確認する方法は？ 私の主な懸念は、ベンダーがコードの変更をプッシュし、APIを破ることです。継続的にテストするための何らかの自動ソフトウェアが必要です。これに対処するには？

14 testing  api  rest  continuous-integration  integration-tests 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新することがありますので、上のトピックソフトウェア工学スタックExchange用。 4年前に閉鎖されました。 コーディング方法を理解しています。私は定期的に使用する言語の基本を回避する方法を知っています。私は少し基本的な正規表現を書く方法を知っています。データベースと話をしたり、入力を受け付けたり、出力を出力したり、ファイルを処理したりできます。やや複雑なプログラム。 私の問題は、それが十分だとは思わないということです。私は自分の言語の標準ライブラリのごく一部しか知らないように感じます。少なくともすべてを理解するまでは、それを使って仕事を得ようとする権利さえありません。私は（コミュニティ/ジュニア/ whathaveyou）大学を卒業したばかりで、友人たちは業界で仕事を得ていますが、それでも私は偽物や物差しのように感じています。 「十分に知っている」ための適切なマーカーはありますか？少なくとも、FizzBu​​zzをコーディングすることができるという事実を、物事に申し込むことは大丈夫だという指標として採用すべきでしょうか？これらの標準ライブラリ、フレームワーク、APIを比較的簡単に学習するにはどうすればよいですか？私は定期的にコーディングし、本を読んでいますが、私の知識はまだとても浅いものです。 助けて！

14 learning  self-improvement  frameworks  api 

私は、サードパーティのREST APIからデータをクエリする新しいプロジェクトに取り組んでいます。これはリアルタイムのスポーツデータフィード用であるため、フィードはゲームが実際に行われているときにのみ機能します。 サードパーティは優れたドキュメント（XSDなど）を提供しますが、ゲームの発生をシミュレートする方法がないため、このAPIに対して記述したコードをテストするには、実際のゲームが発生するのを待つ必要があります。 私の唯一の手段は、自分でゲームをシミュレートするコードを書くことですが、多くの作業のように思えます。これにどのようにアプローチしますか？

13 api  rest 

データ用にRESTful APIを完全に使用するJavaScript Webアプリケーションがあるとします。 このアプリケーションにはデータフォームがあり、/ product / 12345のレコードを編集しているとします。フォームを作成するとき、/ product / 12345にRESTfulリクエストを行い、JSONデータを取得します。 { "id": 12345, "name": "Some Product", "active": true, "sales_user_id": 27 } したがって、私のフォームには、営業担当者を選択するためのドロップダウンリストがあるのは明らかです。このリストを作成する必要があります。 データはどこから取得する必要がありますか？最も一般的なアプローチは何ですか？ / product / 12345要求応答の一部にすることは理にかなっていますか？ { "id": 12345, "name": "Some Product", "active": true, "sales_user_id": 27, "sales_users": [ {"id": 1, "name": "Anna Graham"}, {"id": 2, "name": "Dick Mussell"}, {"id": …

13 api  rest  forms 

私は、依存性注入を使用したテスト可能な設計と、単純な固定パブリックAPIの提供とのバランスを取る方法を検討してきました。私のジレンマは次のとおりです。人々はvar server = new Server(){ ... }多くの依存関係や依存関係のグラフを作成することについて心配する必要はなく、何かをしたいと思うでしょうServer(,,,,,,)。開発中は、IoC / DIフレームワークを使用してすべてを処理するため、あまり心配する必要はありません（コンテナのライフサイクル管理の側面を使用していないため、さらに複雑になります）。 現在、依存関係が再実装されることはほとんどありません。この場合のコンポーネント化は、拡張などの継ぎ目を作成するのではなく、ほとんど純粋にテスト容易性（および適切な設計！）のためです。99.999％の人は、デフォルト構成を使用したいと思うでしょう。そう。依存関係をハードコーディングできました。それをしたくない、テストを失う！ハードコードされた依存関係と依存関係を取得するデフォルトのコンストラクターを提供できます。それは...乱雑で、混乱を招く可能性がありますが、実行可能です。依存関係を受け取るコンストラクタを内部に作成し、ユニットテストでフレンドアセンブリ（C＃を想定）を作成できます。これにより、パブリックAPIは整頓されますが、メンテナンスのために厄介な隠されたトラップが残ります。私の本では、明示的にではなく暗黙的に接続された2つのコンストラクターが一般的に悪い設計になります。 現時点では、私が考えることができる最小の悪についてです。ご意見？知恵？

13 c#  api 

私たちは新しいプロジェクトに取り組んでおり、2人の主任開発者であり、トークンを使用してサーバーとクライアント間の通信を保護する方法の岐路に立っています。 最初の提案：（ワンタイムトークンAKAスタティックトークン） クライアントは、ユーザー名とパスワード、およびcurrent_time（この変数はサーバーのデータベースとクライアント側にも保存されます）をAPIに送信することによってプライマリトークンを要求し、サーバーは入力を解釈し、ハッシュトークンをレンダリングします（例： 58f52c075aca5d3e07869598c4d66648）はデータベースに保存し、クライアントに返します。 クライアントはプライマリトークンを保存し、プライマリトークン+認証要求で送信されたcurrent_time変数を使用して新しいハッシュトークンを作成します（この新しいトークンmain_tokenを呼び出します）。また、サーバーも同じことを行い、同じアルゴリズムを使用して同じトークンを作成します。 クライアントがサーバーAPIを照会するたびに、main_tokenをサーバーに送信します。サーバーは、その中で生成されたトークンをクライアントが送信したmain_tokenと比較します。一致する場合、ユーザーは本物であることを意味します。 2番目の提案：（動的トークン） クライアントは2つのランダムキーを生成します（$ key1 = rand（10000,90000）; $ key2 = rand（10000,90000）;）APIの各リクエストで、クライアントはクエリタイプを使用してハッシュを作成し、複雑なアルゴリズム、およびこれらの2つのキー+ハッシュをサーバーに送信します サーバーは、クライアントで使用されるものと同じアルゴリズムを使用してハッシュを作成し、クライアントが送信したものと比較します。一致する場合、サーバーはクエリの処理に進みます さて、質問は、APIリクエストを保護するために使用する最も論理的で安全な方法はどれですか？

13 security  api 

特に、JavaScriptを介してHTML5フロントエンドで使用されるREST APIを開発しています。このアプリケーションは組織内で使用するためのもので、通常は約300人のユーザーがいますが、1000ユーザー程度までスケールアップしたいと考えています。 通常、APIへの接続はLAN内で行われるため、接続の品質と遅延は良好になりますが、3G / 4Gを介した接続が遅く、遅延が発生する可能性のあるインターネットでの時折の使用は除外されません。 私たちが考えた2つのオプションは次のとおりです。 フロントエンドは、APIに対して複数の非同期呼び出しを同時に行い、インターフェイスのさまざまなコンポーネントをロードします。 長所：シンプル。 短所：サーバーへの接続が増えます。 フロントエンドのコントローラーは、オブジェクトを取得する必要があるパラメーターとして渡すAPIを1回呼び出します。 長所：サーバーへの接続は1つだけですが、サーバーはデータベースに複数の接続を作成します。 短所：フロントエンドとAPIの両方のメカニズムが必要です。設計が複雑になります。 詳細な説明：さまざまなリソース... / Product ... / Locationsなどがあります。これらのリソースは単独で取得できますが、別の抽象的なリソース... / screen？Product＆Locationsが1回の呼び出しで両方を取得します。

12 rest  api  ajax