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

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

5
Joda Time vs Java Time
Jodaは豊富な機能を備えており、標準のJava時間よりも洗練されていますが、常に使用するのが最善とは限りません。JavaコードでJoda TimeとJava Timeのどちらを使用すべきかを判断するにはどうすればよいですか? 要件に応じて適切なガイドラインを選択する方法を示すガイドラインがありますか?
19 java  api  joda-time 

3
デカップリングはRESTのDRYに勝りますか?
既存のJava APIのほとんどの機能を公開するREST APIを構築しています。両方のAPIは、組織内で使用するためのものです。外部で使用するために設計する必要はありません。私は両方のAPIに影響を及ぼしていますが、REST APIを実装しています。Java APIは引き続きローカルアプリケーションに使用されます(「非推奨」ではありません)が、重要な新規開発にはREST APIが使用されます。 Java APIクラスの一部は単なるデータです(プロパティ、ゲッター、セッターを持つBean)。そして少なくともこれらのいくつかは、REST APIを介して(何らかの形で)データ(XMLまたはJSONにマーシャリングされる)として送信するのに意味があります。たとえば、サーバーマシンに関する情報を格納するクラス。これらのデータクラスについて、次の選択に直面しています。 元のJavaクラス(またはサブクラス)をREST APIで直接公開する、または REST API専用の新しいデータ転送クラス(DTOパターン)を作成しますか? いずれにせよ、RESTデータ転送クラスがあります。問題は、オリジナルに注釈を付けるか、新しいものを作成するか(オリジナルのコピーに近い場合があります)です。他の選択肢もありますが、主にこれら2つに焦点を当てます。 #1の引数: DRY(繰り返さないでください) 実装が速い REST APIのアップグレードが簡単 #2の引数: REST APIをJava APIとは別にバージョン管理する必要がある場合はどうなりますか?(これは多少可能性があります。) プロパティの削除、動作の追加、クラス階層の変更など、Javaデータクラスに大幅な変更があった場合はどうなりますか?(これも多少可能性があります。) 要するに、DRY(#1)とデカップリング(#2)の間のトレードオフのように思えます。 #1から始めて、その後#2に移って問題が発生した場合は、必要なことを証明できないものを構築しないというアジャイルガイドラインに従っています。これは悪い考えですか。とにかくそこに行き着くかもしれないと思うなら、私は#2から始めるべきですか? 私のリストに欠けている主要な議論/結果はありますか?
19 java  api  rest  coupling  dry 

5
内部および外部APIアーキテクチャ
私が働いている会社は、長年にわたって「有機的に」成長した成功したSaaS製品を維持しています。既存の製品とデータを共有する一連の新製品でラインを拡大する予定です。これをサポートするために、ビジネスロジックを1つの場所、つまりWebサービスレイヤーに統合することを検討しています。WSレイヤーは以下によって使用されます。 Webアプリケーション データをインポートするツール 他のクライアントソフトウェアと統合するためのツール(APIそのものではありません) また、それを使用して独自の統合を作成できるお客様が使用できるAPIを作成したいと考えています。次の質問に取り組んでいます: 内部API(別名WSレイヤー)と外部APIは同じものであり、セキュリティとアクセス許可の設定により、誰が何を実行できるかを制御するか、外部APIが内部APIを呼び出すだけの2つの別個のアプリケーションである必要があります他のアプリケーションのように?これまでの議論では、それらを分離する方が安全かもしれませんが、オーバーヘッドが追加されます。 同様の状況で他の人は何をしましたか?
19 api  web  web-services 

1
SOA /マイクロサービス:サービス間通信で認証を処理する方法
前景 モノリシックプラットフォームから、よりサービス指向のアーキテクチャに移行しています。非常に基本的なDDDの原則を適用し、さまざまな境界のあるコンテキストにドメインを分割しています。各ドメインは配布され、Web API(REST)を介してサービスを公開します。 ビジネスの性質上、予約、サービス、顧客、製品などのサービスを提供しています。 また、主な役割が以下のことを行うIdentity Server(Thinktecture Identity Server 3ベース)をセットアップしました 認証の集中化(トークンを発行する資格情報を指定) 次のようなトークンにクレームを追加します:クライアントのスコープ(クライアントごとに要求を行うアプリケーションを意味する)、顧客識別子(顧客ごとにアプリケーションを使用する人を意味する) また、サービスへの外部アクセスを集中化するAPI Gatewayの役割も導入しました。API Gatewayは、次のような内部ドメインの深い知識を必要としない機能を提供します。 リバースプロキシ:着信要求を適切な内部サービスにルーティングします バージョン管理:API Gatewayのバージョンは、内部サービスの異なるバージョンにマップされます 認証:クライアント要求には、Identity Serverによって発行されたトークンが含まれ、API Gatewayはトークンを検証します(ユーザーが本人であることを確認してください) 調整:クライアントごとの要求数を制限する 認可 認可に関係するものは、これはAPI Gatewayではなく、内部サービス自体で管理されます。現在、主に2種類の承認を行っています。 クライアントスコープに基づく承認。例:クライアント(APIを使用する外部アプリケーション)には、予約サービスAPIエンドポイントにアクセスするためのスコープ「bookings」が必要です 顧客に基づいた承認。例:顧客(アプリケーションを使用する実在の人物)が予約の参加者である場合のみ、予約サービスからエンドポイントGET / bookingsにアクセスできます。 内部サービスで認証を処理できるようにするために、API Gatewayは、クライアント(要求を行うアプリケーション)と顧客としての情報の両方を含むトークン(内部サービスに要求をルーティングするとき)を転送するだけです人がクライアントアプリケーションにログインしている場合)。 問題の説明 これまでのところ、サービス間通信(一部のサービスは他のサービスと通信してデータを取得できます)を導入するまではこれで十分です。 質問 サービス間通信の認可にどのようにアプローチすればよいですか? 考慮されるオプション さまざまなオプションについて説明するには、次のサンプルシナリオを使用します。 予約フローを構築するために、APIにアクセスするExternalAppと呼ばれる外部アプリケーションがあります(ExternalApp はクライアントとして見ることができます) ExternalAppはBookingsサービスにアクセスする必要があるため、ExternalAppにスコープ「bookings」を付与します 内部的に(これはExternalAppに対して完全に透過的なものです)、予約サービスはサービスサービスにアクセスして、フライト、保険、レンタカーなどの予約のデフォルトサービスを取得します この問題を内部で議論する際、いくつかのオプションが表示されましたが、どのオプションが最適かはわかりません。 BookingsがServicesと通信する場合、API Gatewayから受信した元のトークンを単純に転送する必要があります(クライアントがExternalAppであることを示します) 意味:付与されるべきではないExternalAppにスコープを付与する必要がある場合があります。例:ExternalAppにはスコープ「bookings」と「services」の両方が必要な場合がありますが、「bookings」スコープのみで十分です。 BookingsがServicesと通信する場合、クライアントが(ExternalAppの代わりに)Bookingsになったことを示すトークンを転送し、Bookingsが元のクライアントExternalAppになりすましていることを示すクレームを追加します また、元のクライアントがExternalAppであるという情報を含めることにより、サービスサービスは元の呼び出し元に応じて一部のサービスを除外するなどのロジックも実行できます(たとえば、内部アプリの場合はすべての戦いを返し、外部アプリの場合は一部のみ) サービスは互いに通信すべきではありません(そのため、この質問に直面するべきではありません) ご意見をお寄せいただきありがとうございます。

2
何かを「さらす」とはどういう意味ですか?
だから私はGoogle App Engineアプリケーションの作成に取り組んでおり、「最初のアプリはHTTPベースのAPIを使用してオブジェクトを公開できる」、「このdatamodelクラスを公開する」など、何度も「公開」という用語に出くわしましたREST API」。「露出」とはどういう意味ですか?関連する特定のアクションがありますか、それとも設計の抽象的な部分ですか?

4
Web APIの廃止:ベストプラクティス?
最終的に、パブリックWeb APIの一部を減価償却する必要があります。しかし、私はそれを行うための最良の方法が何であるかについて混乱しています。大規模なサードパーティアプリベースがある場合、ほとんどすべてのアプリが一晩で失敗するため、古いバージョンのAPIをヤンクするだけでは間違った方法のように思えます。ただし、古くなったWeb APIを永久に使用できる状態に維持することはできません。 古いWeb APIを廃止するためのベストプラクティスは何ですか?
18 api 

2
REST APIの設計:複数の呼び出しとAPIの単一の呼び出し
モバイルアプリで使用されるeコマースWebサイト用のRest APIを開発しています。 アプリのホームページでは、スライダー、トップブランド、ベストセラー製品、トレンド製品などの複数のリソースを呼び出す必要があります。 API呼び出しを行うための2つのオプション: シングルコール: www.example.com/api/GetAllInHome 複数の呼び出し: www.example.com/api/GetSliders www.example.com/api/GetTopBrands www.example.com/api/GetBestSellingProducts www.example.com/api/GetTrendingProducts 残りのAPI設計に最適なアプローチはどれですか。単一呼び出しか複数呼び出しか、長所と短所を説明してください。 どちらがリクエストに応答するのに時間がかかりますか?
18 rest  api  api-design  url 

1
APIキーを配置する場所:カスタムHTTPヘッダーとカスタムスキームを使用したAuthorizationヘッダー
APIキーを介した承認/認証を使用してREST APIを設計しています。 最適な場所を見つけようとしましたが、次のようなカスタムHTTPヘッダーの使用を多くの人が提案していることがわかりましたProjectName-Api-Key。 ProjectName-Api-Key: abcde ただしAuthorization、カスタムスキームでヘッダーを使用することも可能です。 Authorization: ApiKey abcde 一方、カスタム認証スキームは、一部のクライアントでは予期せずサポートされず、カスタムコードにつながる可能性があるという考慮事項を見つけました。したがって、クライアントには期待がないため、カスタムヘッダーを使用する方がよいでしょう。 どの方法でAPIキーを送信しますか?

2
APIがhttp基本認証を使用する方法
APIがクライアントの認証を必要とする場合、2つの異なるシナリオが使用されているのを見て、状況に応じてどのケースを使用すべきか疑問に思っています。 例1.サードパーティがHTTP Basicを使用してトークンとシークレットで認証できるようにするために、会社がAPIを提供しています。 例2. APIは、エンドユーザーを認証するためにHTTP Basicを介してユーザー名とパスワードを受け入れます。通常、彼らは将来のリクエストのためにトークンを受け取ります。 私のセットアップ:モバイルアプリおよびWebアプリのバックエンドとして使用するJSON APIを用意します。モバイルアプリとウェブアプリの両方がトークンとシークレットを一緒に送信することをお勧めするので、これら2つのアプリのみが他のサードパーティをブロックするAPIにアクセスできます。 ただし、モバイルアプリとWebアプリでは、ユーザーがログインして投稿を送信したり、データを表示したりすることができます。したがって、各リクエストでHTTP Basicを介してログインすることもできます。 これらの両方の方法を何らかの方法で組み合わせて使用​​するのですか、それとも各要求でエンドユーザーの資格情報(ユーザー名とトークン)のみを送信するのですか?エンドユーザー資格情報のみを送信する場合、クライアントのCookieに保存しますか?

6
この時点で、Javaのパブリックフィールドは悲劇的な歴史的な設計上の欠陥にすぎませんか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 この時点では、オブジェクトの状態にパブリックフィールドを使用することは基本的に決してすべきではないというのは、Javaの正統性のようです。(必ずしも同意するわけではありませんが、それは私の質問とは関係ありません。)それを考えると、今日からJavaのパブリックフィールドが言語設計の誤り/欠陥であったことは明らかです。それとも、今日でも言語の有用かつ重要な部分であるという合理的な議論がありますか? ありがとう! 更新: C#、Python、Groovyなどのよりエレガントなアプローチについて知っています。これらの例を直接探しているわけではありません。バンカーの奥深くにまだ誰かがいるのではないかと思っているだけで、公共の場がどれほど素晴らしいのか、大衆はただの羊なのかなどについてつぶやいています。 更新2:明らかに静的な最終公開フィールドは、公開定数を作成する標準的な方法です。オブジェクトの状態(不変の状態でさえ)にパブリックフィールドを使用することについてもっと言及していました。パブリックフィールドを定数ではなく、状態ではなく使用する必要があるという設計上の欠陥のように思えます。言語のルールは、ガイドラインではなく構文によって自然に実施されるべきです。

3
Web APIはどのように機能しますか?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 Facebook、Twitterなどのような多くのWeb APIを聞いたことがあります。これは、サードパーティがデータにアクセスして操作するのに役立ちます。Web APIの仕組みを知りたいです。Web APIの基本は何ですか? 自分のサイトのAPIを作成して、人々がアクセスしたり更新したりできるようにしたい場合は、まず何をする必要がありますか?

4
複数のHTTPリクエストをマージして帯域幅を節約することをお勧めしますか?
低速のモバイル接続で時々使用される単一ページのアプリケーションを準備しています。その一部は、APIリクエストの点でかなり重い(新しい画面表示のために10個の異なるリソースをフェッチする)。 さて、これらのサービスを、必要なすべてのデータを提供するサービスにマージするのは良い考えですが、RESTの原則に関しては「純粋」ではありませんか?予想される大幅なパフォーマンスの向上はありますか?
16 api  rest  http 

2
RESTful APIでネストされたリソースを使用する場合
ユーザーとリンクの2つのリソースがあります。 ユーザーは複数のリンクを関連付けることができます。次のURIでユーザーに関連付けられたリンクにアクセスできるように、RESTful APIを設計しました。 /users/:id/links ただし、常にリンクだけのURIが必要です。ユーザーに関係なく、すべてのリンクが必要な場合があります。 このために私は: /links これは大丈夫ですか?リンクに2つのURIがありますか? 代わりに、次のようなURIを使用してユーザーのリンクにアクセスする必要があるかどうか疑問に思います。 /links/user/:id または /links/?user=:id この方法では、リンク用のリソースは1つしかありません。
16 api  rest  api-design 

1
ほとんどのAPI Gatewayソリューションで「集計」がサポートされないのはなぜですか?
API Gatewayについて読むと、毎回出てくるものの1つは、API Gatewayが複数のエンドポイントからの結果を集約する場所であるということです。それは本当にいいですね。ただし、AWS API Gateway、Kongo、Netflix Zuulなどの多くの一般的なAPI Gatewayソリューションは、このような機能をサポートしていません。ハックするか、カスタムフィルターを自分で実装する必要があります。 集約は悪い習慣と見なされていますか?複数のエンドポイントから結果を返す方法

1
RESTful APIとi18n:応答を設計する方法は?
主に単一のクライアントのニーズを満たすことを目的としたRESTful APIを設計しています。非常に特殊な状況のため、このクライアントはできるだけ少ないリクエストを作成する必要があります。 APIは、リクエストのAccept-Languageヘッダーを介してi18nを処理します。これは、利用可能なすべてのロケールで単一のエンドポイントへの要求の応答をクライアントが保存する必要がある1つの機能を除き、クライアントが行う必要があるすべてのことに対して機能します。 クライアントが単一のリクエストでこれらすべての情報を取得できるように、一貫性のある適切に構造化されたRESTful API設計を壊さずに、何らかの方法でAPIを設計できますか? これまで検討してきたオプション: Accept-Languageヘッダーに複数のロケールを含めることを許可し、応答で要求されたすべてのロケールのローカライズバージョンを追加します。各ロケールはキーとしてISO 639-1言語コードで識別されます。 そのエンドポイントに「?all_languages = true」パラメーターのようなものを作成し、そのパラメーターが存在する場合、応答で使用可能なすべてのロケールのローカライズバージョンを返します。 (上記のいずれも機能しない場合)ローカライズされたすべてのバージョンをクライアントから取得するために複数のリクエストを作成します。 どれが最良の選択肢ですか?
15 rest  api  api-design  http 

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