ソフトウェア工学 rest

2

モバイル向けのソーシャルベースのアプリケーションを開発しています。すべてのアプリケーションはRESTful API Webサービスを使用します。ログインを実装するとき、通常はユーザー名とパスワードをデバイスのどこかに保存します。次に、それらを送信し、応答として自分のプロファイルにアクセスします。しかし、これを行う別の方法があることも知っています。何らかの方法で特定のアルゴリズムでトークンを生成し、ユーザー名とパスワードの代わりにトークンを送信してアクセスを取得します。どうすれば実装できますか？このトークンをログイン以外のすべてのリクエストとともに送信する必要がありますか？

21 mobile rest login

7

REST APIクライアントとしてのWebアプリケーション：リソース識別子を処理する方法

RESTを実装しようとすると、RESTに関連するいくつかの概念が頭の中で競合します。ビジネスロジックを保持するRESTフルバックエンドAPIシステムと、UIを提供するWebアプリケーションがあります。RESTに関するさまざまなリソース（特に、REST in Practice：Hypermedia and Systems Architecture）から、エンティティの生の識別子を公開せず、でハイパーリンクを返す必要があることを知っていrel="self"ます。例を考えてみましょう。REST APIには、人を返すリソースがあります。 <Person> <Links> <Link rel="self" href="http://my.rest.api/api/person/1234"/> </Links> <Pets> <Link rel="pet" href="http://my.rest.api/api/pet/678"/> </Pets> </Person> 問題はWebアプリケーションで発生します。ブラウザへのハイパーリンクを含むページを返すと仮定しましょう： <body class="person"> <p> <a href="http://my.web.app/pet/???????" /> </p> </body> href属性に何を入れるべきですか？ユーザーがターゲットページを開いたときにエンティティを取得できるように、WebアプリケーションにAPIエンティティURLを保持するにはどうすればよいですか？要件は矛盾しているようです：ハイパーリンクhrefは、UIをホストするシステムであるため、Webアプリケーションにつながるはずです hrefウェブアプリが対象ページが開いたときに、エンティティに対処することができなければならないので、エンティティのいくつかのIDを持っている必要があります WebアプリはRESTに対応していないため、REST URLを解析/構築しないでください。 URIは消費者に対して不透明でなければなりません。URIの発行者だけが、それを解釈してリソースにマップする方法を知っています。その1234ため、RESTfulクライアントとしてのように扱う必要があるため、API応答URLから取得することはできませんhttp://my.rest.api/api/AGRIDd~ryPQZ^$RjEL0j。一方、WebアプリにつながるURLを指定する必要があり、アプリが何らかの方法でAPIの元のURLを復元し、そのURLを使用してAPIリソースにアクセスするには十分です。最も簡単な方法は、おそらくリソースのAPI URLを文字列識別子として使用することです。しかし、そのようなWebページのURL http://my.web.app/person/http%3A%2F%2Fmy.rest.api%2Fapi%2Fperson%2F1234は見苦しいです。デスクトップアプリや単一ページのjavascriptアプリにとっては、すべて簡単に思えます。彼らは継続的に生きているので、アプリケーションの存続期間中、サービスオブジェクトとともにURLをメモリに保持し、必要なときにそれらを使用することができます。 Webアプリでは、いくつかのアプローチを想像できますが、すべてが奇妙に見えます： API URLのホストを置き換えて、結果のみを保持します。大きな欠点は、APIが生成するURLを処理するためにWebアプリケーションが必要になることです。つまり、巨大な結合を意味します。さらに、私のWebアプリがURLの解釈を開始するため、再びRESTfulではありません。 REST APIで生のIDをリンクとともに公開し、それらを使用してWebアプリのURLを作成し、WebアプリサーバーでIDを使用してAPIで必要なリソースを見つけます。これは優れていますが、Webアプリはブラウザーからの要求を処理するために何らかのフォームのget-by-id要求のチェーンを発行するRESTサービスナビゲーションを通過する必要があるため、Webアプリサーバーのパフォーマンスに影響します。ある程度ネストされたリソースの場合、これにはコストがかかる場合があります。 selfAPIから返されたすべてのURLをWebアプリサーバーの永続的な（DB？）マッピングに保存します。それらのIDを生成し、IDを使用してWebアプリページのURLを構築し、RESTサービスリソースのURLを取得します。つまり、http://my.rest.api/pet/678URLを新しいキー（たとえば3）で保持し、WebページのURLをとして生成しますhttp://my.web.app/pet/3。これは、ある種のHTTPキャッシュ実装のように見えます。理由はわかりませんが、奇妙に思えます。または、それはすべて、RESTful APIがWebアプリケーションのバックエンドとして機能できないことを意味しますか？

21 web-applications rest

4

REST vs RESTful vs「通常の」Webサービス-同じかどうか

RESTやRESTfulアプリケーションに関する定義と議論をいくつか読みましたが、それが本当の意味をまだ理解していません。私は通常、GETを介してデータを取得するか、POSTを介してデータベースからデータを取得するかデータベースに書き込むWebサービス（通常はPHPスクリプト）にデータを送信するアプリを使用します。さて、これはRESTfulアプリですか？そうでない場合、RESTfulアプリはどうなりますか？RESTfulコンセプトとこれまでに取り組んだコンセプトの違いは何ですか？例で説明してください。また、誰かがRESTについて話し、誰かがRESTfulアプリについて話します。RESTという用語は理論的な概念を指すのに対して、特定のアプリについて話すときにはRESTfulが使用されることがわかりました。これは正しいのですか、それともRESTアプリとRESTfulアプリの間に本当の違いがありますか？

21 java php web-services mobile rest

5

パブリックREST APIのOAuth2 ROPCと基本認証

ここで興味のある特定のユースケースは、公開されているサーバーエンドポイント（公開REST APIなど）に対してRESTクライアントを認証することです。ここで最も簡単なソリューションは、基本認証です。しかし、ほとんどすべての状況において、OAuth2が優れた認証ソリューションとして宣伝されているとよく耳にします。事は、あるのみ RESTサーバに対してRESTクライアント認証のために実現可能であるのOAuth2許可タイプがあるリソース所有者のパスワードの資格情報（ROPC）コード補助金と暗黙の補助金がため（認証サーバによってホストされている）UI / Webページを必要とするため、ログインしてクライアントアプリを手動で承認するユーザー。 ROPCが機能する方法は、リソース所有者のユーザー名/パスワードとクライアントIDをクエリ文字列パラメーターとして送信することです。これは、少なくともBase-64が資格情報をエンコードし、TLSで暗号化できるヘッダー内に送信するBasic Authよりも安全性が低い（IMHO）です！だから私は尋ねる：パブリックREST APIのコンテキストでは、OAuth2 ROPCは本当に基本認証よりも優れていますか？OAuth2 ROPCより安全なものは何ですか？更新 AmazonのAWS向けの非OAuth2ベースのRESTセキュリティを説明するこの素晴らしい記事を読んだところです。これは基本的に、各RESTリクエストのハッシュが生成され、通常の（暗号化されていない）リクエストと一緒にサイドカーとして送信される秘密鍵ベースのソリューションです。クライアントとサーバーのみが秘密鍵を知っているため、サーバーがリクエストを受信すると（再び、通常のリクエスト+ハッシュされたリクエストを含む）、サーバーはクライアントの秘密キーを検索し、同じハッシュを通常のリクエストに適用し、次に、2つのハッシュを比較します。これは、OAuth2のROPCよりもはるかに複雑で、複雑で、安全に聞こえます！ここで重要な何かを見逃していない限り、OAuth2 ROPCは単に送信client_idしてusernameおりpassword、クエリ文字列パラメーターとして...完全に完全に安全ではありません！このHMAC /ハッシュベースのソリューションは、はるかに印象的で安全なようです。問題は、その記事の著者でさえ次のように述べていることです。また、ある時点でOAuthを実装する必要があることをゆっくりと認識し、受け入れます。バババウト？！？！OAuth2がこの賢いHMAC /ハッシュベースのソリューションよりも安全性が低い場合、この記事の著者はなぜOAuthをいつか受け入れる必要があると感じるのでしょうか。私は困惑している。

21 rest oauth https

4

クライアントがとにかくそれを利用するのに十分に進歩していないとき、REST APIの「発見可能性」の必要性は何ですか？

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

20 rest api hateoas

1

OAuthの代替手段

Web業界は、APIサービスを外部の消費者と開発者に拡張する際にOAuthを使用する方向に移行/移行しています。シンプルなものにはいくつかの優雅さがあります...そして、3ステップのOAuthプロセスはそれほど悪くはありません...私はそれが最良の選択肢であることに気づきました。より優れた、より安全な代替手段はありますか？セキュリティ参照は、次のURLから派生しています。 OAuth 2.0はWebに悪いですか？ Webに悪い署名のないOAuth 2 ITセキュリティスタックエクスチェンジでこれに遭遇しましたが、セキュリティの観点からはそれが痛烈だと思いました。 OAuth / OpenID / Facebook Connect ..クレイジー？たぶんSAML 2.0が代替手段ですか？何についてのOpenIDの？この質問の目的は、プログラミングの観点からです。 OAuthは今日存在する最良のオプションですか？セキュリティの観点、実装の観点、長寿命（数か月でやり直す必要はありません）、Webを消費するモバイルアプリケーションのサポートを可能にする消費者にWebアプリケーションを拡張できる代替オプションがありますか応用。

20 web-applications websites rest

5

RESTfulアーキテクチャの長所と短所[非公開]

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 RESTの長所と短所に関して私が見た最も一般的な議論は、SOAPに関連する議論を組み立てる傾向があります。私も経験がありません。私は現在、自分の経験の不足が評価を難しくしている決定に直面しています。私は、いくつかのコンポーネント（主に所有者が複数のサイトを管理できる管理面）と、ユーザーがホストに保持されているデータとやり取りできる公開ユーザーインターフェイスを備えたアプリケーションの開発を始めています。後者の部分をどこでもホストし、RESTfulアーキテクチャを介して前者と通信できるようにすること、または両方のコンポーネントが同じホストに存在することを要求することの意味を評価する必要があります。RESTfulアーキテクチャを開発することの重要な意味は何ですか、特に次の分野での能力に関して： 1：セキュリティ2：パフォーマンス3：インターフェイスの複雑さ編集：この質問への答えのいくつかを見て-私は明確にする必要があります。SOAPとの比較を探しているのではなく、RESTアプリケーションとすべてのコンポーネントが1つのホストに存在するアプリケーションの概要を探しているわけではありません。（しかし、それらの答えに感謝！）

20 web-applications rest

4

サーバーのビジネスロジックエラーを表すためにHTTPステータスコードを使用する必要がありますか？

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

20 rest api web

3

DDDアプリケーションサービスとREST APIの概念的な不一致

複雑なビジネスドメインと、REST API（厳密にはRESTではなく、リソース指向）をサポートする要件を持つアプリケーションを設計しようとしています。リソース指向の方法でドメインモデルを公開する方法を考えるのに苦労しています。 DDDでは、ドメインモデルのクライアントは、手続き型「アプリケーションサービス」層を通過して、エンティティおよびドメインサービスによって実装されるビジネス機能にアクセスする必要があります。たとえば、ユーザーエンティティを更新する2つのメソッドを持つアプリケーションサービスがあります。 userService.ChangeName(name); userService.ChangeEmail(email); このアプリケーションサービスのAPIは、状態ではなくコマンド（動詞、プロシージャ）を公開します。ただし、同じアプリケーションにRESTful APIも提供する必要がある場合は、次のようなユーザーリソースモデルがあります。 { name:"name", email:"email@mail.com" } リソース指向のAPIは、コマンドではなく状態を公開します。これにより、次の懸念が生じます。 REST APIに対する各更新操作は、リソースモデルで更新されているプロパティに応じて、1つ以上のアプリケーションサービスプロシージャコールにマップできます。各更新操作は、REST APIクライアントにとってアトミックに見えますが、そのようには実装されていません。各アプリケーションサービス呼び出しは、個別のトランザクションとして設計されています。リソースモデルの1つのフィールドを更新すると、他のフィールドの検証ルールが変更される可能性があります。したがって、すべてのリソースモデルフィールドを一緒に検証して、潜在的なすべてのアプリケーションサービスコールが有効になるようにしてから、それらを作成する必要があります。一連のコマンドを一度に検証することは、一度に1つずつ実行することほど簡単ではありません。個々のコマンドが存在することすら知らないクライアントでそれをどのように行うのでしょうか？アプリケーションサービスメソッドを異なる順序で呼び出すと効果が異なる場合がありますが、REST APIは違いがないように見えます（1つのリソース内）もっと似たような問題を思いつくかもしれませんが、基本的にはすべて同じことが原因です。アプリケーションサービスを呼び出すたびに、システムの状態が変化します。有効な変更のルール、エンティティが次の変更を実行できるアクションのセット。リソース指向のAPIは、すべてをアトミック操作のように見せようとします。しかし、このギャップを越える複雑さはどこかに行かなければならず、それは巨大なようです。さらに、UIがよりコマンド指向である場合（多くの場合そうです）、クライアント側でコマンドとリソースをマッピングし、API側に戻す必要があります。質問：このすべての複雑さを（厚い）RESTからAppServiceへのマッピングレイヤーで処理するだけですか？または、DDD / RESTの理解に何か不足していますか？ RESTは、特定の（かなり低い）複雑度でドメインモデルの機能を公開するために、単に実用的ではないでしょうか？

20 architecture rest domain-driven-design

1

ネストされたREST URLと親ID、どちらが優れた設計ですか？

さて、2つのリソースがAlbumありSongます：と。APIは次のとおりです。 GET,POST /albums GET,POST /albums/:albumId GET,POST /albums/:albumId/songs GET,POST /albums/:albumId/songs/:songId 私たちはいくつかの歌が嫌いであることを知っていSusyます。たとえば、と呼ばれます。どこにsearch行動を起こすべきか？別の質問。さて、今ではもっとリアルになっています。アルバム1を開き、すべての曲を読み込みます。JSオブジェクトを作成します。それぞれが曲データを保持しremove、次のようなメソッドはほとんどありませんupdate。曲オブジェクトにはID、名前、およびものがありますが、どの親に属しているかについての手がかりはありません。これは、クエリによって曲のリストを取得するためです。私が間違っている？だから、私はいくつかの解決策を見ますが、私は本当に確信がありません。親IDをオプションにします-get-parameterとして。私は現在このアプローチを使用していますが、butいアプローチだと感じています。 List,Create /songs?album=albumId Update,Delete /songs/:songId Get /songs/?name=susy # also, solution for first question ハイブリッド。OPTIONSメタデータを取得するためのクエリを実行するためにアルバムIDが必要なため、今では便利です。 List,Create /album/:albumId/songs Update,Delete /songs/:songId POST /songs/search # also, solution for first question 各リソースインスタンスで完全なURLを返します。APIは同じですが、次のような曲を取得します。 id: 5 name: 'Elegy' url: /albums/2/songs/5 このアプローチはHATEOASと呼ばれると聞きました。だから...親IDを提供するには id: 5 …

19 design design-patterns rest ajax

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

3

WebアプリケーションでRPCのようなメカニズムの代わりにRESTが一般的に使用されるのはなぜですか？

私はごく最近、少なくとも私が知っている典型的なWebアプリケーションフレームワークと比較して、Webアプリケーションにかなり珍しいカスタムフレームワークを使用している会社で働き始めました。RESTful Webサービスの代わりに、RPCメカニズムを使用してサーバーと通信します。サーバーとの通信は単純な関数呼び出しのように見えますが、関数はクライアントではなくサーバー上で実行されます。サーバー側には、クライアントが呼び出すことができる機能を定義する方法があります。これをhttpリクエストに変換する方法の詳細は完全に抽象化されています。私は今これを短い時間だけ使用しましたが、それはかなり便利なようです。しかし、私はこのアプローチのどのような欠点が欠けているのか疑問に思っています。他の誰もが違うやり方をしているように見えますが、これは通常、前者に比べてはるかに高い確率で、私が愚かで素晴らしいことをしているかもしれないというサインです。

18 web-applications rest rpc

5

RESTful APIは、物がないことを表します

人が霊獣を選択したかどうかを識別するAPIを想像してください。彼らはゼロまたは1つのスピリット動物しか持つことができません。現在： /person/{id}/selectedSpiritAnimal 動物が選択されると、http 200が返され、 {selectedAnimal:mole} ただし、選択がない場合は、http 404が返されます。これは、HTTPエラーとして、まだスピリット動物を選択していない有効なドメインの懸念を表しているため、スピリット動物を不幸にします。さらに、ビジネスとして-erm Sprit-Animal-Hampers-R-us-誰かに選択がないときを知りたいので、それらを促すことができます。ここでより良い応答は何ですか： HTTP 200および {selectedAnimal:null} またはさらに明示的に HTTP 200および {selectedAnimal:null, spiritAnimalSelected: false} それとも、404を返す方が良いでしょうか？this image has not yet been uploadedオンラインで画像を表示するときは404によく似ているのでthis person has not selected a spirit animal、この質問は重複として提案されていますが、その質問は、URLが表す変更を許可しないようにアプリケーションが構成されている場合に要求される有効なURLに対処します。一方、ここでは、リソースが存在しないことが意味のあるリソースをどのように表すかを検討しています。つまり、クライアントがURLを要求することは有効であり、応答は、モノの不在を表すリソースを正常に要求したということです。だから、これは「ビジネスロジック」ではなく、物の不在が意味を持っている状況です（404がまだ正しいと主張している多くの同僚がいるかもしれません）が、それをどのようにマッピングするのかわかりませんスペック答えを選ぶのは非常に難しい。ここでの会話と職場で進行中の会話について、何度も考えを変えました。ここで落ち着いているのは、仕様書には4xxはクライアントが間違っているときだと言われているということです。この例では、クライアントはselectedSpiritAnimal URLからの応答を予期するように指示されているため、エラーはありません。私の同僚の間のコンセンサスは、これは悪いAPI設計の症状であるということですおそらく/ person / {id}をリクエストし、その人のリンク関係のセットを返す方が良いでしょう...もし/ selectedSpiritAnimalリンクが与えられていない場合（人に選択がない場合）とにかくそれを呼び出すと、404が理にかなっています。または、クライアントがデータのサブセットを要求しない限り、部分応答を実装し、/ person / {id}がより完全なドキュメントを返すようにすること

18 rest

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キーを送信しますか？

17 rest api authentication authorization headers

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

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