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

アプリケーションプログラミングインターフェイス(API)は、ソフトウェアが他のソフトウェアで使用されることを意図した仕様です。

9
外部APIからの予期しない値から保護する必要がありますか?
外部APIから入力を受け取る関数をコーディングしているとしましょうMyAPI。 その外部APIにMyAPIは、a stringまたはa を返すことを示す契約がありnumberます。 それはのようなものから保護することをお勧めしますnull、undefined、booleanそれはのAPIの一部ではないにもかかわらずなど、MyAPI?特に、そのAPIを制御することはできないため、静的型分析などの方法で保証することはできません。 私はロバストネスの原則に関連して考えています。

10
「お住まいの地域ではサービスを利用できません」というエラーのHTTPステータスコードは何ですか?
現在、5つの都市でサービスを提供しています。誰かが他の都市からサービスAPIを呼び出そうとした場合、このエラーをスローしますService not available in your area。 問題は、このエラーに適切なhttpコードは何ですか? 503:サービスを利用できません 403禁止します または、他の何か?
51 api  api-design  http 

3
SOAPの現在の意味は何ですか
最後に、SOAPベースのサービスに出くわしたのは、2013年に金融会社でインターンシップを行っていたときです。それが、ITでのキャリアを始めたときでした。私のエンジニアリングコースの1つで、SOAPについての学習資料を持っていたことを覚えています。それ以外では、私はキャリアの中でSOAPをあまり使用していません。 「SOAPとRESTの違い」という質問が最近のインタビューの1つで出てきたので、私はこれを尋ねています。私が知っていること(およびGoogleで発見したこと)から、SOAPは、ビジネスロジックに密接に関連する情報交換のためにクライアントとサーバーを密結合したプロトコルです。一方、RESTはデータ転送のためのより柔軟なステートレスアーキテクチャです。 SOAPとRESTのこの違いについて間違っている場合、誰かが私を修正してくれますか?また、SOAPの現在の重要性は何ですか?人々はまだ新しいSOAPベースのAPIを開発していますか、それとも今はほとんどレガシーですか?
51 rest  api  web-services  soap 

3
複雑なRESTful検索メソッドを実行する適切な方法は何ですか?
RESTの原則に従って、いくつかの基準を使用して検索を行い、結果をクライアントに返すAPIのGETメソッドを作成します。問題は、基準に最大14個のパラメーターを設定できることです。そのうちの1つは複雑なオブジェクトのリストです。 これらの複雑なオブジェクトをURLパラメータとの間でエンコード/デコードできるかどうかさえわかりません。 URLが取得できる時間は計算しませんでしたが、十分に大きく、URLの長さの制限に達すると確信していますか? また、検索は結果を「リアルタイム」で表示する必要があります。つまり、ユーザーが検索フォームから何かを変更するたびに、「検索」ボタンを押さなくても新しい結果を表示できるはずです。 これらの点を明確にして、多くのパラメーターを使用して安らかな検索方法を作成することをお勧めしますか?
44 rest  api 

3
DOMの何が悪いのですか?
DOMはひどいAPIであると言っている人々(特にCrockford)の声を聞き続けていますが、この声明を正当化するものではありません。ブラウザー間の不整合は別として、DOMがそれほど悪いと考えられる理由は何ですか?

3
APIクライアントの単体テストを実際に行う価値はありますか?
これは今しばらく私を悩ませてきたものです。APIクライアントの単体テストを実際に行う価値はありますか? petshop REST APIへの呼び出しを抽象化するための小さなクラスを作成しているとしましょう。petshopは非常に単純なAPIであり、基本的なメソッドセットがあります。 listProducts() getProductDetails(ProductID) addProduct(...) removeProduct(ProductID) これをテストするには、モックサービスを作成するか、応答をモックする必要があります。しかし、それは行き過ぎのようです。タイプミス/構文エラーによってメソッドの動作が停止しないことを確認したいのですが、リモートメソッドを呼び出す関数を作成し、それらのリモートメソッドから偽の応答を作成しているため、努力の無駄であり、実際に失敗することのない何かをテストしています。さらに悪いことに、リモートメソッドが変更された場合、本番環境の使用が失敗している間にユニットテストに合格します。 何かが足りないのか、スティックの端が間違っているのか、木の代わりに木が見えないのはかなり確かです。誰かが私を正しい軌道に乗せることができますか?
38 unit-testing  api 

8
企業内で内部APIキーを共有しないようにするにはどうすればよいですか?
新しいサービスに取り組んでいます。このサービスは、ユーザーのデバイス上のアプリケーションから直接呼び出される可能性があります。これらのアプリケーションは、提供するデータに応じて、組織全体の複数の開発チームによって開発およびサポートされます。 使用パターンと責任のある開発者を特定できるように、どのアプリケーションがどのリクエストを送信しているかを特定したいと考えています。(疑念を避けるため、ユーザー認証は個別に処理されます。) 私たちのソリューションは、アプリケーションごとに1つのAPIキーを必要とすることです。その後、開発チームの連絡先の詳細を取得します。 APIキーを摩擦の原因にしたくはありませんが、開発者がそれらを他のチームの同僚と共有するのではないかと心配しています。つまり、1つのアプリケーションだけのトラフィックを識別できなくなります。 APIキーを内部で共有しないように開発者にインセンティブを与えるにはどうすればよいですか?

5
メソッドを呼び出すことができると定義するよりも、メソッドをオーバーライドできると定義する方が強いコミットメントはありますか?
から:http : //www.artima.com/lejava/articles/designprinciples4.html エーリッヒガンマ:10年経った今でも、それは真実だと思います。継承は、動作を変更するクールな方法です。しかし、サブクラスは、オーバーライドするメソッドが呼び出されるコンテキストについて簡単に推測できるため、脆弱であることがわかっています。私がプラグインするサブクラスコードが呼び出される暗黙的なコンテキストのため、基本クラスとサブクラスの間には密接な結合があります。構成には、より良い特性があります。結合は、いくつかの小さなものをより大きな何かにプラグインするだけで減少し、大きなオブジェクトは小さなオブジェクトをコールバックします。APIの観点から、メソッドをオーバーライドできることを定義することは、メソッドを呼び出すことができることを定義することよりも強力です。 私は彼が何を意味するのか理解していません。誰か説明していただけますか?

8
(ほぼ)任意のプログラミング言語から呼び出すことができる一連の関数を作成するにはどうすればよいですか?
言語バインディング(または他のフレームワーク)を介して他のプログラミング言語からアクセスできるAPIを作成する方法を見つけたいです。これを行うことは可能ですか?もしそうなら、どのプログラミング言語が「クロスランゲージ」APIを書くのに最も適しているでしょうか?私の目標は、使用しているプログラミング言語からアクセスできる単一の関数セットを作成し、各言語でAPI全体を手動で書き直す必要がないようにすることです。
33 api  languages  binding 

3
パブリックAPIで(列挙)型を表現する方法
私は自分のクライアントに使用し、将来一般に公開したいシンプルなAPIに取り組んでいます。異なる「タイプ」を持つことができる「アイテム」オブジェクトがあります。型はCの「typedef enum」です。 typedef enum { ItemTypeBool, ItemTypeNumber, ItemTypeDate, } ItemType; (将来、いくつか追加するかもしれません) 整数として転送するのか、定義された「文字列」として転送するのかを考えています。JSONは次のようになります。 整数の場合: { "name": "The name", "type": 0, ... } 文字列の場合: { "name": "The name" "type": "boolean" ... } これにベストプラクティスがあるかどうか疑問に思っています。整数を保持すると、コードが若干単純化され、帯域幅が削減されますが、開発者は文字列を覚えやすくなります。私はプロジェクトに取り組んだことを思い出し、1 = image、2 = audio、3 = htmlを思い出さなければなりませんでした。 あなたが私が考慮すべき他の側面を知っているなら、私はあなたに尋ねています。

2
Webサイトは独自のパブリックAPIを使用する必要がありますか?
私はウェブサービスを書き始めており、nodeJSとRESTfulなアプローチで構築しました。 私が収集したものから: 利点は、コードを複製する必要がないことです。 欠点は次のとおりです。 パブリックAPIは頻繁に更新されますが、バージョン管理で解決する必要があります サービス固有のキャッシュと最適化を実際に行うことはできません ベストプラクティスと見なされるものは何ですか?Stack Exchange、Github、Twitterなどのサイトは、クライアント用に独自のAPIを使用していますか?
31 api 

9
インターフェースの命名:接頭辞「Can-」と接尾辞「-Able」
インターフェイスのサフィックスとして「-able」を使用するのが一般的です Serializable Printable Enumerable Drinkable Shootable Rotatable 「Can-」の方がわかりやすいので、もっと良いかもしれないと考えていました。はい、より冗長であり、インターフェイス名にノイズを追加します。特に、受動動詞を使用できます。 例えば、Shootableは、オブジェクトが射撃できることを意味します(銃がこれを実装する場合があります)、または射撃できることを意味します(ターゲットボードがこれを実装する場合があります)。「Can-」プレフィックスを使用すると、前者は「CanShoot」になり、後者は「CanBeShotAt」または「CanShootAt」になります。 例2ドキュメント「CanBePrinted」とプリンター「CanPrint」 または、「-Able」に固執し、ドキュメントにコンテキストを提供させますか? ご意見。
29 api  interfaces 

2
DBテーブル名は単数形であるがRESTfulリソースは複数形である必要があると慣習で規定されているのはなぜですか?
少なくともSQLでは、データベーステーブル名は単数形である必要があるという、かなり確立された規則です。この質問と議論をSELECT * FROM user;参照してください。 また、RESTful APIリソース名は複数にする必要があるという確立された規則です。GET /users/123そして、これをPOST /users見てください。 最も単純なデータベースベースのAPIでは、URLのリソースの名前はテーブルになり、URLのデータ要素と要求/応答本文はDBの列に直接マップされます。概念的には、この理論的なAPIを介してデータを操作することと、SQLを介して直接操作することとの間に違いはありません。そして、そのため、間の命名規則の違いuserとはusers私には意味がありません。 概念的に、REST APIとSQLが同じことをしているときに、複数形の違いをどのように正当化できますか?

4
Web API認証テクニック
人々のGetリクエストにxml / jsonを提供するasp.net MVC Webサービスフレームワークがありますが、ユーザーを認証するための最良の方法(javascriptまたはOO言語でコーディングするユーザーにとって高速、簡単、簡単)を見つけるのに苦労しています。データが機密であるなどということではなく、ユーザーに登録してもらい、変更を通知して使用状況を追跡するための電子メールアドレスを用意するだけです。 以前の試みでは、URIにユーザー名があり、ユーザー名が存在することを確認し、使用に応じてdbテーブルをインクリメントするだけでした。これは非常に基本的なことでしたが、ユーザー名などとしてデモを使用している人がいることに気付くので、もう少し洗練させる必要があります。 利用可能な認証技術は何ですか?主要なプレーヤーは何を使用/しますか。
26 security  api  web  services  rest 

1
REST API-モバイル固有の課題
モバイル側で、新しいiOSアプリプロジェクトに取り組んでいます。いくつかのアーキテクチャの変更が行われているため、構築中のアプリやWebサイトなどの他のクライアントが使用するカスタムビルドのプライベートAPIに依存する必要があります。 設計されているAPIは、HTTP動詞にマップされるリソース中心のURIおよびCRUD操作のRestスタイルに従います。次のようなもの: GET www.example.com/books DELETE www.example.com/books/482094 POST www.example.com/users/6793 問題は、このスタイルでは、多くの場合、モバイルクライアントが単一のアプリ画面の読み込みや単一のユーザーUIアクションの管理を行う必要が生じることです。これにより、必要なものがすべて揃うまで、アプリは8秒間ロードモードになります。低速で応答しないアプリ。 接続に関しては、モバイルクライアントには重大な制限があるため、理想的には次のようなルールに従う必要があります。 1画面== 1 API呼び出し 1保存== 1 API呼び出し。 これにより、REST設計の原則との衝突コースに入る多くの状況があります。例: アプリが1日間オフラインで、バックエンドデータベースの4つのテーブルと同期する必要があり、次のような呼び出しが必要だとします www.example.com/sync_everything?since=2015-07-24 ユーザーが自分のオブジェクトの多くを編集できる画面があるとしましょう。たとえば、todoリストでタスクをチェックします。編集ごとに1つのAPI呼び出しを行うのではなく、1つのバッチAPI呼び出しですべてのタスクレコードを編集する方法が必要です。 ORDER、SALESMEN、およびPRODUCT dbテーブルからの情報を混合する画面があるとしましょう。3つではなく1つの呼び出しでそのデータを取得する必要があります。 リスクは、最も安らかなAPIが存在し、また、最も役に立たない無反応のモバイルアプリが存在する可能性があることです。 問題は、私はただの新しい請負業者であり、私が必要なのは、私がそれらのポイントを作るのに役立つもの、尊敬される情報源からの記事、またはそのようなものです。モバイルクライアントのRESTスタイルで妥協している主要なプレーヤー(例:複合集計APIエンドポイントの使用による)。 または、この一般的な問題の解決策。ありがとう!
25 rest  api  ios  mobile 

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