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

RESTful APIを必要とする新しいJavaプロジェクトを開始しています。モバイルクライアントにサービスを提供するSaaSビジネスアプリケーションになります。 Java EE 6を使用して1つのプロジェクトを開発しましたが、ほとんどの経験がMicrosoftプラットフォームに関するものであるため、エコシステムについてあまり詳しくありません。 記載されているような新しいプロジェクトのJAX-RS実装の賢明な選択はどれでしょうか？ ウィキペディアのリストから判断すると、主な候補者はジャージー、Apache CXF、RESTeasy、Restletのようです。しかし、Wikipediaで引用されているJAX-RS実装の比較は 2008年のものです。 それぞれのホームページから私の最初の印象は次のとおりです。 CXFは非常に包括的なソリューションを目指しています（Microsoft分野のWCFを思い出させます）。これは、必要なものよりも理解、セットアップ、デバッグが複雑になると思います。 Jerseyはリファレンス実装であり、良い選択かもしれませんが、Sunの遺産であり、Oracleがそれをどのように扱っているのかわかりません（アナウンスページが機能せず、最後のコミット通知が4か月前のものです）。 RESTeasyはJBossからのもので、おそらく堅実なオプションですが、学習曲線についてはわかりません。 Restletは人気があるように見えますが、多くの歴史があります。JavaEE 6の世界でどの程度最新であるか、または（多くのXML構成のように）重いJ2EEの考え方を持っているかどうかはわかりません。 これらの各選択肢のメリットは何でしょうか？学習曲線はどうですか？機能サポート？ツール（例：NetBeansまたはEclipseウィザード）？デバッグと展開の容易さについてはどうですか？これらのプロジェクトのうち、他のものよりも最新のものはありますか？それらはどれくらい安定していますか？

35 java  rest  java-ee 

私が現在理解しているように、HATEOASは基本的に、次に何をすべきかについての情報を各応答リンクと共に送信することに関するものです。簡単な例の1つは、インターネット上で簡単に見つかります：銀行システムとアカウントリソース。この例は、アカウントリソースへのGET要求後のこの応答を示しています GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK <?xml version="1.0"?> <account> <account_number>12345</account_number> <balance currency="usd">100.00</balance> <link rel="deposit" href="/account/12345/deposit" /> <link rel="withdraw" href="/account/12345/withdraw" /> <link rel="transfer" href="/account/12345/transfer" /> <link rel="close" href="/account/12345/close" /> </account> データとともに、次に何ができるかを示すリンクがあります。残高がマイナスの場合、 GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK <?xml version="1.0"?> <account> <account_number>12345</account_number> <balance currency="usd">-25.00</balance> <link rel="deposit" href="/account/12345/deposit" /> </account> 入金のみできるように。Fiddlerを使用している場合、またはブラウザーで要求を行っている場合、何ができるかを簡単に確認できます。この種の情報は、APIの機能を発見するのに役立ち、サーバーはクライアントから切り離されます。 ただし、ポイントは、Javascriptを使用したSPAやAndroidアプリなど、クライアントを構築するときに、HATEOASがどのように関連し続けるかを見ることができないということです。つまり、SPAをJavaScriptでコーディングしている場合、コードを記述するためにAPIで何ができるかを知る必要があります。 …

35 rest  client-server  hateoas 

ドメイン駆動設計とRESTの両方をサービス指向アーキテクチャに適用しようとしているプロジェクトに取り組んでいます。100％REST準拠について心配する必要はありません。リソース指向のHTTP API（〜RichardsonのREST成熟度モデルのレベル2）を構築しようとしていると言った方が良いでしょう。それでも、RPCスタイルのHTTPリクエストの使用は避けようとしています。つまり、例えば、POSTdo を使用するのではなく、RFC2616に従ってHTTP動詞を実装しようとしますIsPostalAddressValid(...)。 ただし、これに重点を置くことは、ドメイン駆動設計を適用しようとする試みを犠牲にしているようです。だけではGET、POST、PUT、DELETEおよびその他のいくつかのほとんど使用されない方法で、私たちは汚いサービスを構築する傾向があり、そして汚いサービスは、貧血のドメインモデルを持っている傾向があります。 POST：データを受信し、検証し、データにダンプします。GET：データを取得して返します。実際のビジネスロジックはありません。また、サービス間でメッセージ（イベント）を使用しますが、ビジネスロジックのほとんどは最終的にその周りに構築されるように思われます。 RESTとDDDは何らかのレベルで緊張していますか？（または、ここで何かを誤解していますか？他の何か間違っているのでしょうか？）RPCスタイルのHTTP呼び出しを回避しながら、サービス指向アーキテクチャで強力なドメインモデルを構築することは可能ですか？

34 rest  domain-driven-design  domain-model 

次の形式のURLがあります / instance / {instanceType} / {instanceId} 標準のHTTPメソッドで呼び出すことができます：POST、GET、DELETE、PUT。ただし、「下書きとして保存」や「キュレート」など、いくつかのアクションがあります ドラフト、検証、キュレートなどのカスタムHTTPメソッドを使用できると考えました 基準が言うので、これは許容できると思います 「HTTP / 1.1の共通メソッドのセットを以下に定義します。このセットは拡張できますが、追加のメソッドは、個別に拡張されたクライアントとサーバーで同じセマンティクスを共有することはできません。」 また、WebDavなどのツールは独自の拡張機能を作成します。 カスタムメソッドで誰かが遭遇した問題はありますか？プロキシサーバーとファイアウォールを考えていますが、他の懸念事項は大歓迎です。安全な側にとどまり、action = validate | curate | draftのようなURLパラメーターを設定するだけですか？

34 rest  http 

HTTP API応答に関する何らかの標準はありますか？ この談話スレッドを読んだ後、私は疑問に思い始めました。私の仕事ではパブリックHTTP JSON APIを開発していますが、厳密に必要でない場合は何も返しません（たとえば、/ resource / {id}へのPUTは、OKまたは対応する4XXまたは5XXコードのときに200のみを返しますが、 JSON本体） {"success":true}上記のリンクで説明したようなジェネリックを返す必要がありますか、それとも「void」ボディを返してすべてをhttp応答コードで処理しても大丈夫ですか？

33 rest  api-design  http 

Steve VinoskiによるREST、Reuse、Serendipityに関するこの講演を見た後、（XML-）RPC-ishセットアップのグリーンフィールドプロジェクトにRESTがより良い方法で解決できなかったビジネスケースがあるのではないかと思います。 彼が言及したいくつかのRPC問題： 言語に焦点を当てる（分散システムをその言語に適合させ、その逆ではない） 「ローカルに見えるようにする」（およびルールではなく例外として障害と遅延に対処する） 言語に依存しないことを意図しているが、依然として主要な成分として言語間で「関数呼び出し」を持っている IDLボイラープレート 型の安全性の錯覚 そして、さらにいくつか... 少しドラマ化するために、RPC vs RESTのGoogleインスタント結果をいくつか示します。

33 web-services  rest  use-case  rpc 

過去2つの会社では、Webアプリを介してデータを照会するためにREST APIを使用していました。すなわち。Webアプリに直接SQLを実行させる代わりに、REST APIを呼び出し、SQLを実行して結果を返します。 私の質問は...なぜこれが行われるのですか？ 第三者にさらされるとしたら、理解できました。完全なDBよりも制限されたREST APIを公開する方が適切です。しかし、これらの企業の両方ではそうではありません。 これらのREST APIを使用すると、DBMSを簡単に切り替えることができるようになりました。しかし、それはデータベース抽象化レイヤー（DBAL）のポイントではありませんか？ORMをDBALとして使用するか、生のSQLを記述し、必要に応じてDBALにDB固有のものを変換させることができます（たとえば、MySQLのLIMITをMSSQLのTOPに変換します）。 いずれにせよ、それは私には不要のようです。また、問題の診断も難しくなると思います。Webアプリのレポートが間違った数値を提供している場合、SQLクエリをダンプすることはできません。RESTURLをダンプしてから、REST APIとして機能するプロジェクトに移動して、そこからSQLを取り出す必要があります。そのため、診断プロセスの速度を低下させる間接的な余分なレイヤーです。

32 database  web-applications  rest  web-api 

パスワードの設定/リセットにも使用されるREST APIがあるとします。また、これがHTTPS接続で機能すると仮定します。そのパスワードを呼び出しパスに入れない正当な理由はありますか、BASE64でエンコードすることもできますか？ 例として、次のようなパスワードをリセットします。 http://www.example.com/user/joe/resetpassword/OLDPASSWD/NEWPASSWD BASE64は暗号化ではないことを理解していますが、この場合はショルダーサーフィンのパスワードを保護したいだけです。

31 rest  passwords 

SOAPの消費にはSOAPスタックが必要であることがわかります。したがって、クライアントは消費するのが難しくなります。つまり、POSTデータとヘッダーを正しくフォーマットしてから、データ構造ですが、RESTではクエリ文字列の引数を使用してHTTP GETリクエストを作成し、おそらくXMLであると思われるテキストを取得します。 それでは、SOAPの余分なオーバーヘッド/複雑さは何をあなたに与えますか、いつそれを必要としますか？

30 web-services  rest  soap 

異なるロールを持つ複数のユーザーが含まれるリソースにアクセスできるREST APIを構築しています。 スコープをシンプルに保つために、「student / teacher / class」ドメインを取り上げます。 GET /students アクセスするリソースです。 ユーザーには、学生や教師などの役割がある場合があります 生徒はクラスの生徒にのみアクセスできます。教師は、教えるクラスの生徒にアクセスできます。いくつかの用途は学生であり、他のクラスも教えます。彼らは彼らのクラスの生徒と彼らが教えるクラスの生徒にアクセスできなければなりません。 理想的には、これを2つの機能として実装します。ロールごとに1つ、ユーザーが複数のロールを持つ場合は「結合」します。 私の質問は、これを実装するためにどのパターンを使用すればよいですか？ 外部的に ロールごとにAPIを分割する必要がありますか？GET /teacher/studentsそしてGET /student/studentsそれは右の私には思われません。 すべてを維持する私は1つのリソースです（推奨） 内部的に 内部的にどのように実装する必要がありますか？ すべての方法は、BIGスイッチで開始する必要がありますか、役割ごとに行う必要がありますか 役割ごとにリポジトリを実装する必要がありますか？ これを達成するのに役立つ設計パターンはありますか？ 副次的なコメントとして：私はASP.NET Web APIとEntity Framework 6を使用していますが、概念的な実装には関係ありません。

27 design-patterns  programming-practices  rest  web-api 

適切にRESTfulなアプローチを広範に使用するプロジェクトに着手しようとしています。つまり、HATEOASを使用し、クライアントによる一般的な調査を可能にする方法でリソースを提供します。 クライアントアプリケーションをさまざまな言語で自動的に生成できるように、エンドポイントの説明を確実に提供したいと思います。SOAPベースのWebサービスにはWSDLを使用できること、およびRESTで使用されているHTTP動詞の定義を強化するWSDL2があるようです。しかし、その有用性をめぐって多くの記事が行き来しています。 したがって、外部コードジェネレーターがWebアプリケーション用のクライアントを迅速に構築できるようにWADLを使用する必要がありますか、それとも期待されるより良い標準がありますか？

27 web-applications  rest  standards 

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

27 rest  api  sql  conventions  naming-standards 

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

26 security  api  web  services  rest 

モノリシックREST APIをマイクロサービスアーキテクチャに移行することを検討していますが、データストレージについて少し混乱しています。私が見るように、マイクロサービスの利点のいくつかは次のとおりです。 水平方向にスケーラブル-負荷やサーバーのダウンに対処するために、マイクロサービスの複数の冗長コピーを実行できます。 疎結合-他のマイクロサービスを変更することなく、マイクロサービスの内部実装を変更できます。また、独立して展開および変更することもできます。 私の問題はデータストレージです。ご覧のとおり、いくつかのオプションがあります。 すべてのマイクロサービスで共有される単一のデータベースサービス-これは、疎結合の利点を完全に排除するようです。 各マイクロサービスにローカルにインストールされたデータベースインスタンス-これを水平方向にスケーリングする方法が見当たらないため、オプションとは思わない。 各マイクロサービスには独自のデータベースサービスがあります-疎結合と水平スケーリングの利点を保持するため、これは最も有望であると思われます（冗長データベースコピーの使用および/または複数でのシャーディング） 私には、3番目のオプションが唯一のオプションのように思えますが、私には信じられないほど重く、非常に過剰に設計されたソリューションです。私がそれを正しく理解している場合、4-5マイクロサービスを備えたシンプルなアプリケーションでは、16-20サーバーを実行する必要があります-マイクロサービスごとに2つの実際のマイクロサービスインスタンス（サーバー障害の場合、およびダウンタイムなしでデプロイするため）、およびマイクロサービスごとに2つのデータベースサービスインスタンス（サーバー障害などの場合）。 これは、率直に言って、少しばかげているようです。16〜20台のサーバーでシンプルなAPIを実行しますが、現実的なプロジェクトにはおそらく4〜5以上のサービスがあることに留意してください。これを説明する基本的な概念がありませんか？ 回答中に役立ついくつかのこと： 私はこのプロジェクトの唯一の開発者であり、近い将来になります。 Node.jsとMongoDBを使用していますが、言語に依存しない回答に興味があります。答えは、間違ったテクノロジを使用しているだけかもしれません。

25 architecture  rest  api-design  microservices 

モバイル側で、新しい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