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

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 6年前に閉鎖されました。 ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 優れたAPIが優れている理由は何ですか？「1つのことをして、それをうまくやる」というマントラに従うことは良い兆候であり、存在することは問題領域への良いマッピングであることが重要であると思いますが、素晴らしいAPIには何が共通していますか？

15 api-design 

私は多くのユーザーをサポートするアプリケーションを開発しています。問題は、クライアント/ユーザーを認証する方法がわからないことです。 私はhttp://quickblox.com/のようなアプリを構築しています。そこでユーザーに資格情報を提供し、ユーザーはそれらを使用してユーザー名とパスワードを入れて認証を取得できないNアプリケーションを構築します。 それが次のようになると仮定しましょう。（QuickBloxと同じように） 1.ユーザーが私のWebサイトでアカウントを作成します。 2.ユーザーはN個のAPIキーを作成し、資格情報を秘密にすることができます。（複数のアプリの場合） 3.ユーザーは、アプリケーション（Android、iOS、Javascriptなど）でこれらの資格情報を使用して、REST APIと通信します。（REST APIには読み取りおよび書き込みアクセスがあります。） 私の懸念？ ユーザーは自分が作成したアプリケーションに資格情報（APIキーと秘密キー）を入れます。誰かがこれらのキーを取得して、ユーザーをまねようとするとどうなりますか？（APKを逆コンパイルするか、JavaScriptコードを直接調べます。 どこか間違ってる？この3つのレベルのユーザーメカニズムを設計するのは混乱しています。

14 design-patterns  architecture  api-design  authentication  enterprise-architecture 

私はサービスの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 

単一ページアプリケーションにREST APIを提供するASP.NET Web APIがあります。DTO / POCOを使用して、このAPIを介してデータを渡します。 問題は、これらのDTOが時間とともに大きくなっていることです。そのため、DTOをリファクタリングしたいと考えています。 DTOを設計する「ベストプラクティス」を探しています。現在、値型フィールドのみで構成される小さなDTOがあります。 public class UserDto { public int Id { get; set; } public string Name { get; set; } } 他のDTOは、構成によってこのUserDtoを使用します。例： public class TaskDto { public int Id { get; set; } public UserDto AssignedTo { get; set; } } また、他から継承することによって定義される拡張DTOがいくつかあります。たとえば： public class …

13 rest  api-design  web-api  dto  poco 

私はRESTful Webサービスの設計に関する研究を行ってきましたが、重要な決定点と思われるものに到達したため、アドバイスを得るためにコミュニティに提供すると思いました。 RESTfulアーキテクチャの原則に沿って、発見可能なAPIを提示したいので、さまざまなHTTP動詞を可能な限り完全にサポートします。私の難しさは、これらのリソースの表現の選択にあります。ご覧のとおり、検索結果の表示方法や他のリソースへのリンクの提供方法を​​カバーする独自のAPIを思い付くのは簡単ですが、これは私のアプリケーションに固有のものです。 Atom Publishing Protocol（RFC 5023）、およびODataがその使用を促進する方法について読んだことがありますが、（現在の）かなり単純なAPIに対して抽象化のレベルを追加するようです。 だから私の質問は、開発者が表現の選択としてAtomPubを選択する必要があるのはいつですか？そうでない場合、現在推奨されているアプローチは何ですか？

13 web-services  rest  api-design 

この男が言うことに基づいて：http : //toddfredrich.com/ids-in-rest-api.html UUIDを使用してAPIリソースを識別することについて彼が正しいと仮定します。次に、そのように実装しようとすると問題が発生します。これは次のとおりです。 class FooEntity { final String id = null; //auto-generated by my backend (mongodb), not shared final UUID uid = UUID.randomUUID(); //the resource id } （クライアントとサーバー間では、データベースエンティティではなく、送受信されるDTOです。） 問題は、id私がもう使用していないので役に立たないということです。クライアントがリクエストを行うuidので、なぜ2つのIDを処理する必要があるのですか？次に、最初の同じ問題に戻ります。UUIDを主キー（_id）として設定すると、バックエンドIDが公開されます。 そのほかに、効率性のトピックがあります。ObjectIdによるインデックス作成はUUIDよりもはるかに効率的であると読みました。

13 database  api-design  mongodb 

既に5回前後に切り替えました。このRESTエンドポイントは/api/tags/内部で使用するものであり（サードパーティのクライアントはありません）、私がそれを使用しているのは私だけです。 私はこれらの2つの表現の間で決定しています： 平らな { "types":[ { "id":1, "text":"Utility" }, { "id":7, "text":"Lease Terms" }, ], "tags":[ { "id":8, "text":"Water", "type":1 }, { "id":9, "text":"Electricity", "type":1 }, { "id":5, "text":"Minimum 12 month lease", "type":7 }, { "id":17, "text":"lease negotiable/flexible", "type":7 }, ] } ややモジュール化されています。互換性を損なうことなく、「国」などの別の最上位レイヤーを追加できます。 入れ子 { "1":{ "text":"Utility", "tags":{ "8":{ "text":"Water" …

12 rest  api-design  json 

私はRESTful APIを設計していますが、タイトルの問題に直面しました。 クライアントが認識されないパラメーターを送信した場合、高速で失敗する必要がありますか？例えば、 http://example.com/api/foo?bar=true&paula=bean 上記でbarは、は有効なパラメーターですがpaula、APIによって指定されていません。したほうがいい クライアントにエラーを警告する 早く失敗する それを無視します クライアントに警告する場合、最初のパラメーターに対して警告を発行できるのは、ほぼ無限の数のパラメーターを送信している可能性があり、サーバーにはおそらくより良いことがあるからです。同様に、失敗すると、最初の無効なパラメータのみが問題として指定されます。 警告を出すよりもプログラマーに強制的に行動を起こさせるよりも失敗を好む。そうでなければプログラマーは問題を無視してリソースを浪費し続けるかもしれない。その点で何もしないのはさらに悪いことです。 私の議論は理にかなっていますか？そのようなことに関して受け入れられている慣行はありますか？

12 rest  api-design 

私はPythonからRustへの移植に取り組んでおり、RustでPythonほど自然に表現できないコードに遭遇しました。 これの1つのケースは、デフォルトのパラメーターを使用することです。 class Foo: def __init__(self, a="Hello"): self._a = a Rustでは、ビルダーを使用してこれを実装できます。 struct FooBuilder { a: &'static str, } struct Foo { _a: &'static str } impl FooBuilder { fn new() -> FooBuilder { FooBuilder { a: "Hello", } } fn change_a(self, new_a: &'static str) -> FooBuilder { FooBuilder { a: …

12 api-design  porting 

私はHTTP APIの設計を進めており、できればできるだけRESTfulにするようにしています。 機能がいくつかのリソースに広がるアクションがいくつかあり、いつか元に戻す必要があります。 これはコマンドパターンのように思えますが、どのようにリソースにモデル化できますか？ DepositActionのようなXXActionという名前の新しいリソースを紹介します。 POST /card/{card-id}/account/{account-id}/Deposit AmountToDeposit=100, different parameters... これにより、実際に新しいDepositActionが作成され、そのDo / Executeメソッドがアクティブになります。この場合、201 Created HTTPステータスを返すことは、アクションが正常に実行されたことを意味します。 後でクライアントができるアクションの詳細を確認したい場合 GET /action/{action-id} Update / PUTはここでは関係ないため、ブロックする必要があります。 そして、アクションを元に戻すために、私は DELETE /action/{action-id} 実際に関連オブジェクトのUndoメソッドを呼び出し、そのステータスを変更します。 やり直しが1回だけで満足だとしましょう。やり直す必要はありません。 このアプローチは大丈夫ですか？ 落とし穴、それを使用しない理由はありますか？ これはクライアントのPOVから理解されていますか？

12 design-patterns  api  rest  api-design  http 

C ++ライブラリの優れたAPIデザインについて学び、共有オブジェクト/ dllなどを調べるための優れたリソースを探しています。ソースレベルでの優れたAPI、優れたクラス、テンプレートなどの記述に関する多くのリソースがありますが、共有ライブラリと実行可能ファイルに物事をまとめる。John LakosのLarge-Scale C ++ Software Designのような本は興味深いものですが、非常に時代遅れです。 私が探しているのは、テンプレートの取り扱いに関するアドバイスです。APIのテンプレートでは、実行可能ファイル（または他のライブラリ）にライブラリコードが含まれることが多いため、そこでバグを修正すると、新しいライブラリを単純に展開することはできませんが、そのコードのすべてのクライアントを再コンパイルして再配布する必要があります。（そして、はい、少なくともライブラリ内の最も一般的なバージョンをインスタンス化するなどのいくつかのソリューションを知っています。） また、C ++ライブラリでの作業中にバイナリ互換性を維持するために注意すべき他の注意事項や事柄も探しています。 そのようなことに関する良いウェブサイトや本はありますか？

12 c++  libraries  api-design  dll 

私は「依存性注入の原則、実践、およびパターン」という本を読んでおり、この本で十分に説明されているリークのある抽象化の概念について読んでいます。 最近では、依存関係の注入を使用してC＃コードベースをリファクタリングし、非同期呼び出しをブロックの代わりに使用しています。そうすることで、コードベースの抽象化を表し、非同期呼び出しを使用できるように再設計する必要があるいくつかのインターフェイスを検討しています。 例として、アプリケーションユーザーのリポジトリを表す次のインターフェースについて考えてみます。 public interface IUserRepository { Task<IEnumerable<User>> GetAllAsync(); } 本の定義によれば、リークの多い抽象化は特定の実装を念頭に置いて設計された抽象化であり、一部の実装は抽象化自体を通じて「リーク」します。 私の質問は次のとおりです。IUserRepositoryなどの非同期を念頭に置いて設計されたインターフェイスを、漏れやすい抽象化の例として検討できますか？ もちろん、可能なすべての実装が非同期と関係があるわけではありません。アウトプロセス実装（SQL実装など）だけが必要ですが、インメモリリポジトリは非同期を必要としません（実際にインメモリバージョンのインターフェイスを実装する方がおそらくインターフェースが非同期メソッドを公開している場合は困難です。たとえば、メソッドの実装でTask.CompletedTaskまたはTask.FromResult（users）のようなものを返す必要がある場合があります。 あれについてどう思う ？

12 c#  object-oriented  api-design  interfaces  dependency-injection 

ハイフン（ケバブケース）を使用するJSONキーへのアクセスに関する多くの質問が表示されますが、今ではキーにキャメルケースまたはsnake_caseを使用するべきかどうか疑問に思っています。言語間で移植すると、ハイフンが複雑なマッピングを作成することもあります。一部のJSONデシリアライズライブラリがこれらのキーをcamelCaseスタイルに変換するのを見てきました。 例： var something = { "some-value": 'thing' } 対 var something = { "someValue": 'thing', "some_other_value": 'thing_two' }

12 javascript  api  api-design  json  web-api 

MVCは非常に単純です。モデル、コントローラー、ビューがあります。Webサイトを作成すると、クライアントがRESTキーワード要求をサーバーに送信するときにすべてがまとめられます->サーバーは要求されたURLをコントローラーアクションに一致させます->データ収集/処理のためにモデルを呼び出し、結果を取得します->そして、結果をHTMLページ（ビュー）としてクライアントに返します。 純粋なRESTful API Webサービスについて話している場合はどうなりますか？次に、クライアントはRESTキーワード要求をサーバーに送信します->サーバーは要求されたURLをコントローラーアクションに照合します->データ収集/処理のためにモデルを呼び出し、結果を取得して->戻ります結果をJSONでクライアントに返します。以前と同じですが、「ビュー」はありません...むしろ、生成されたJSONは「ビュー」と考えることができます。ある意味では、MVCのMC部分のみを使用しています。それはどのように行われるべきですか？または、MVCの代わりにAPIのみのサービスに適した他のパターンはありますか？

12 design-patterns  mvc  rest  api  api-design