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

システム間で（ビジネスレベルで）APIについて議論するとき、チームには2つの異なる視点があります。一般的な抽象アプローチを好む人もいれば、そうでない人もいます。 例：単純な「個人検索」APIの設計。具体的なバージョンは searchPerson(String name, boolean soundEx, String firstName, boolean soundEx, String dateOfBirth) 具体的なバージョンを支持する人々は言う： APIは自己文書化されています わかりやすい 検証は簡単です（コンパイラーまたはWebサービスとして：スキーマ検証） キッス 私たちのチームの他のグループは、「これは単なる検索条件のリストです」と言うでしょう。 searchPerson(List<SearchCriteria> criteria) と SearchCritera { String parameter, String value, Map<String, String> options } おそらくいくつかの列挙型の「パラメータ」を作成します。 支持者は言う： API（の宣言）を変更することなく、実装は変更できます。たとえば、基準やオプションを追加します。展開時にそのような変更を同期しなくても。 具体的なバリアントでもドキュメントが必要です スキーマ検証は過大評価されており、多くの場合、さらに検証する必要があります。スキーマはすべてのケースを処理できません 別のシステムと同様のAPIが既にあります-再利用 反論は 有効なパラメーターと有効なパラメーターの組み合わせに関する多くのドキュメント 他のチームにとって理解するのがより難しいので、より多くのコミュニケーション努力 ベストプラクティスはありますか？文献？

25 api  web-services  api-design 

C ++プログラマーは、ライブラリ/製品のパブリックAPIをC APIとして公開するべきだと言う人をよく耳にします。 それは何を意味し、その利点は何ですか？

25 c++  c  api 

MVCパターンを使用してWebアプリケーションを構築しています。この種のアーキテクチャに従うと、データベースとのやり取りに使用されるすべてのメソッドがモデルに実装されていることがわかります。 しかし、Web上で他の人に公開されているサービスを呼び出さなければならない場合はどうなりますか？たとえば、ページのフォロワーをすべて取得するためにFacebook APIにアクセスしたいので、これらのメソッドをどこに配置しますか？ このモジュールはプレゼンテーション専用であり、コントローラーを使用してデータを取得することはできませんが、モデルは通常データベースとの対話専用であるため、ビューは明らかに良いアイデアではありません。 それで、それについてのヒントを教えていただけますか？そして、MVCアーキテクチャについて間違いを犯していないかどうか教えてください。

25 mvc  api 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 HTTPベースのAPIと呼び、URIを使用してリソースとHTTP動詞（PUT、POST、DELETE、GET ...）に名前を付け、それらのリソースを操作しますか？ ロイ・フィールディングの苦情によると、ハイパーメディアがないため、RESTではありません。 内部的には、私のチームでは、誰もが「REST API」と呼んでいます。私はそれを「RESTライク」と呼んでいますが、説明的ではなく、その意味はあいまいです。RESTについては大きな意見の相違があるため、私はそれについてかなり混乱しています。火炎戦争に参加したくないのですが、正しい用語を使用してください。

24 terminology  rest  api  http 

新しいAPIやプログラミング言語、または単純なLinuxのマニュアルページに出会うたびに、私は常に（覚えている限り）それらを避け、代わりに新しい概念の理解を得るために例に頼りました。 無意識のうちに、私はドキュメンテーション/ APIを、それが単純明快で、不可解であるか、または単なる退屈でないときは避けます。プログラミングを始めてから何年も経ちましたが、今では公式の例よりも百万倍優れているので、不可解な/難しい文書を読むことを控えることでより多くの損害を引き起こしていることに気づき、自分の道を修復する必要があると感じていますドキュメントには、他の例よりも多くの記事があります。例が学習のための「主要な」ソースの代わりに「追加された」値として扱われるべきであることに気付いた後でさえ。 プログラマとしてこの悪い習慣を打破するにはどうすればいいのでしょうか？

23 programming-practices  api 

リソースを持つWebアプリケーションと、別の同様のリソースを持つリモートアプリケーションへの参照があるシステムを想定して、「ローカル」リソースを「リモート」リソースと同期する双方向同期アクションをどのように表現しますか？ 例： ToDoリストを表すAPIがあります。 GET / POST / PUT / DELETE / todos /など そのAPIは、リモートTODOサービスを参照できます。 GET / POST / PUT / DELETE / todo_services /など APIを介してプロキシ経由でリモートサービスから仕事を操作できます GET / POST / PUT / DELETE / todo_services / abc123 /など TodoのローカルセットとTODOSのリモートセット間で双方向の同期を行う機能が必要です。 ある種のRPCでは、次のことができます POST / todo_services / abc123 / sync / しかし、「動詞は悪い」という考えでは、このアクションを表現するより良い方法はありますか？

23 api  rest  api-design  synchronization 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 今日、私はJavaプログラミング試験にほとんど合格しませんでした。スレッド化に関するいくつかの一般的な質問によく答えたので、それよりも少しだけスレッド化されたプログラムを書く必要がありました。私はラップトップをプロジェクターのスクリーンに接続し、すぐにプログラムを書く必要がありました。私の最初の試みは匿名クラスを使用することでしたが、正確な構文を忘れていました。たぶん、いくつかの興奮のためか、最後の2週間はほとんどphpでコーディングしていたためかもしれません。次に、APIドキュメントの使用を許可するかどうかを尋ねました。答えは「いいえ」でした。それで、私は別の方法を試すことにし、Runnableを実装しました。プログラムは、最後に要求されたことを実行していました。もちろん、試験官は私の最初の失敗に気付き、それが私のスコアに大きな影響を与えました。APIドキュメントの使用が許可されていないことに驚きました。 だから、私の質問は次のとおりです。APIドキュメントなしで完璧にコーディングできることは本当に重要ですか？このスキルを開発する必要がありますか？それは現実の世界と作業環境で本当に重要ですか？プログラミングコースでは、学習パターン、優れたデザインアプリケーションを作成するスキル、APIを使用して必要な情報をすばやく見つけるスキルの開発に焦点を当てました。APIドキュメントなしでプログラミングする方法を学ぼうとしていませんでした。就職の面接（API文書なしのコーディング）中に必須アイテムですか？

22 java  self-improvement  api  skills 

アプリケーションをサービスに分割しようとしているとしましょう。SOAアプローチを採用する理由と、それを必要とするアプリケーションがロードできるライブラリAPIを作成する理由はありますか。

22 api  soa  services 

私は新しいビジネスWebアプリケーションを作成しています。 それぞれの領域から最高の技術を使用します。堅牢なORMを備えた信頼性の高いバックエンドフレームワークが必要です。そして、フロントエンドアプリケーションの最新のHTMLおよびJavascript機能を使用した、最も高度なSPA（単一ページアプリケーション）フレームワークが必要です。 さまざまなタイプのアプリケーション（たとえば、Webアプリケーション、モバイル（Android）、および場合によっては他のタイプ（スマートデバイスなど））から使用するバックエンドエンティティとビジネスサービスを公開します。 したがって、両方の要件を満たすために、バックエンドアプリケーションとフロントエンドアプリケーションでアプリケーションを完全に分離し、REST API（JSON）を使用してそれらの間の通信を整理する傾向があります。これは健全なアプローチですか？ 多くのWebアプリケーションテクノロジーには、サーバーサイドアプリケーションがビューの生成を多少制御し、ビューからの応答を部分的に処理するビューレイヤーが統合されているため、このような分離は明白な設計ソリューションではありません（たとえば、ビューレイヤーを持つSpringMVC、ビューを持つPHP Yii Java JSF / Faceletsは、サーバー上のコンポーネントの状態を完全に保存します）。そのため、より強力な結合を提案し、開発時間の短縮とより標準的な道のりを約束する多くの技術があります。だから-広く使われていない方法で技術を使い始めるとき、私は注意しなければなりません。 私が理解したように、完全に分離されたSPAフロントエンドは通常、サードパーティAPIを使用する必要性から生じます。しかし、バックエンドとフロントエンドの両方が1つの会社によって開発されたとき、そのようなデカップリングサウンドデザインはありますか？ 私が現在選択しているテクノロジーは、Java / Springバックエンドとフロントエンド用のAngular2 / Web Components / Polymerです。この質問は一般的な設計に関するものであり、具体的な技術の選択に関するものではないため、それはこの質問とは無関係です。

21 design  rest  api  front-end  backend 

私はプログラミングに多少慣れており（私は貿易で機械エンジニアです）、ダウンタイム中に工場周辺のさまざまな人々からの入力に基づいて（solidworks）パーツを生成する小さなプログラムを開発しています。 わずかな入力（正確には6つ）に基づいて、それぞれ最大12個のパラメーターを取ることができる何百ものAPI呼び出しを行う必要があります。すべては、パーツを処理するすべての人にインタビューした後に収集した一連のルールによって生成されます。私のコードのルールとパラメーターのセクションは250行で、成長しています。 だから、コードを読みやすく管理しやすくする最良の方法は何ですか？すべてのマジックナンバー、すべてのルール、アルゴリズム、およびコードの手続き部分をどのように区分するのですか？非常に詳細で詳細なAPIに対処するにはどうすればよいですか？ 私の主な目標は、誰かに私の情報源を渡して、私の入力なしで、私がやっていることを彼らに理解させることです。

21 api  readability  business-rules 

最近、私は自分のAPIを開発しており、そのAPI設計への投資に興味を持ち、API設計を改善する方法に強い関心を持っています。 数回登場した側面の1つは（私のAPIのユーザーによるものではなく、トピックに関する私の観察中の議論による）です。 たとえば、談話レポについてはGitHubでのこの議論を参照してください。 foo.update_pinned(true, true); （パラメータ名、ドキュメントなどを知らずに）コードを見るだけでは、何をしようとしているのか推測できません。2番目の引数はどういう意味ですか？推奨される改善策は、次のようなものにすることです。 foo.pin() foo.unpin() foo.pin_globally() そして、それは物事を明確にします（2番目の引数はfooをグローバルに固定するかどうかでした、私は推測しています）、この場合、後者は確かに改善されることに同意します。 ただし、コードを見ただけでは何をしているのかわからない場合でも、異なるが論理的に関連する状態を設定するメソッドが、個別のメソッド呼び出しではなく、1つのメソッド呼び出しとしてより適切に公開される場合があると思います。（したがって、パラメータ名とドキュメントを調べて調べる必要があります-個人的には、APIに不慣れな場合は常に何をしてもかまいません）。 たとえばSetVisibility(bool, string, bool)、FalconPeerで 1つのメソッドを公開し、次の行を確認するだけです。 falconPeer.SetVisibility(true, "aerw3", true); あなたはそれが何をしているのか分からないでしょう。falconPeer論理的な意味での「可視性」を制御する3つの異なる値を設定しています。パスワードのみで参加要求を受け入れ、検出要求に応答します。これを3つのメソッド呼び出しに分割すると、APIのユーザーは、「可視性」のすべての側面を設定するために1つのメソッドを公開するだけで他のユーザーに設定を忘れさせる「可視性」の側面を設定することになります。さらに、ユーザーが1つのアスペクトを変更する場合、ほとんどの場合、別のアスペクトを変更する必要があり、1回の呼び出しで変更できます。

20 programming-practices  naming  api  api-design 

OSの本で、「パブリックAPIは永遠に存在します。それを正しく実現するチャンスは1つだけです」と読みました。本当ですか？オペレーティングシステムのAPIまたは他のAPIにも適用できますか？たとえば、これはTasker、Locale、PushoverなどのAndroidアプリケーションのAPIに当てはまりますか？

20 android  api  api-design 

私が見たさまざまな講演やRESTでスキャンしたチュートリアルは、「発見可能性」と呼ばれるものを強調しているようです。私の限られた理解では、この用語は、クライアントがアクセスできることを意味するようですhttp://URL-できることのリストを自動的に取得します。 私が理解できないのは、「ソフトウェアクライアント」は人間ではないということです。これらは、提供されたリンクをどうするかを正確に理解するための直感的な知識を持たない単なるプログラムです。Webサイトにアクセスして、表示されたテキストとリンクを理解し、それに基づいて行動できるのは人々だけです。 クライアントの人間の開発者が提示されたリソースを実際に実験しない限り、そのような発見可能なURLにアクセスするクライアントコードが実際に何もできないとき、発見可能性のポイントは何ですか？これは、ドキュメンテーションマニュアルで利用可能な機能のセットを定義するのとまったく同じように見えますが、異なる方向からだけで、実際には開発者のためにより多くの作業を伴います。なぜ、実際のRESTリソースの外部のドキュメントで実行できることを事前定義するこの2番目のアプローチが劣っていると考えられますか？

20 rest  api  hateoas 

私は、クライアント（ブラウザーのJS）がサーバーと通信するためのAPI設計との岐路にあります。HTTP 409 Conflictを使用して、安全ロックが有効であるためにアクションが失敗することを表します。satefyロックは、開発者がお客様の生産システムを誤って変更することを防ぎます。特定のAPI呼び出しが失敗した理由を示すために、クライアントで409をもう少し優雅に処理するように任されました。 私の解決策は、409が原因で何かが失敗したときにクライアントに通知を表示するAJAX呼び出しの失敗ハンドラーをラップすることでした-これはすべて問題なく、同じメカニズムを使用する他の4XXおよび5XXエラーと一緒にうまく機能します。 ルートハンドラーの1つがビジネスロジックエラーに遭遇したときに409で応答するという問題が発生しました-私のAJAXラッパーは安全ロックがオンであることを報告しますが、クライアントの既存の障害ハンドラーは問題が何に基づいている（考えている）かを報告します応答の。簡単な解決策は、安全ロックを表すために使用するハンドラーの応答またはステータスコードを変更することです。 それが私の岐路に私を連れて行きます：HTTPステータスコードはビジネスロジックエラーを表すためにも使用されるべきですか？この質問は、私が直面しているのと同じ問題に対処しますが、あまり注目を集めませんでした。リンクされた回答で示唆されているように、ビジネスロジック内の障害を表すために適切なボディでHTTP 200 OKを使用することに傾倒しています。 ここに強い意見はありますか？誰かがこれを失敗を表す間違った方法だと私に納得させることができますか？

20 rest  api  web 

最近、RESTfulより優れていると主張するGraphQLについて学びました。しかし、なぜ単純にSQLステートメントをHTTP GETリクエストに入れないのだろうと思い始めました。 たとえば、GraphQLでは次のように記述します { Movie(id: "cixos5gtq0ogi0126tvekxo27") { id title actors { name } } } これは、対応するSQLよりもそれほど単純ではありません SELECT id, title FROM movies WHERE id = cixos5gtq0ogi0126tvekxo27; SELECT actors.name FROM actors, actors_movies WHERE actors.id == movies.actor_id AND movie.id == cixos5gtq0ogi0126tvekxo27; クエリをURLエンコードしてサーバーに送信することができます GET endpoint?q=SELECT%20id%2C%20title%20FROM%20movies%20WHERE%20id%20%3D%20cixos5gtq0ogi0126tvekxo27%3B%0ASELECT%20actors.name%20FROM%20actors%2C%20actors_movies%20WHERE%20actors.id%20%3D%3D%20movies.actor_id%20AND%20movie.id%20%3D%3D%20cixos5gtq0ogi0126tvekxo27%3B HTTP/1.1 はい、クエリURLは長すぎる可能性がありますが、RESTへの準拠を気にしない場合は、POST要求の本文に含めることができます。（ところで、RESTが意味をなすようにHTTP RFCを改訂する必要があると思います：クエリ文字列の長さを制限することは、実装を最初の段階で仕様と混合します） クライアントからSQLを直接発行することには、次の利点もあります。 GraphQLを解析するためにサーバー側のコード/ライブラリは必要ないため、開発時間が短縮されます。 GraphQLを解析するためにサーバー側のオーバーヘッドは必要ないため、実行時間が短縮されます。 SQLステートメントは、GraphQLよりもはるかに柔軟性があります。なぜなら、ほとんどの場合、後者はSQLに還元されるからです。 誰もがSQLを知っています。 それでは、GraphQLがSQLより優れている点は何ですか？

20 architecture  database  web-development  api  web-services