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

RESTを学びましたが、CRUDによく似ています（CRUDについて読んだことから）。 私はそれらが異なっていることを知っています、そして、それらが似ていると思うことは私がそれらを理解しないことを意味するのだろうか。 RESTはCRUDの「スーパーセット」ですか？CRUDでできることはすべてありますか？

168 rest  crud 

RESTfulインターフェースを設計する場合、要求タイプのセマンティクスは設計に不可欠であると見なされます。 GET-コレクションの一覧表示または要素の取得 PUT-コレクションまたは要素を置き換えます POST-コレクションまたは要素を作成する DELETE -まあ、ERM、コレクションや要素を削除 ただし、これは「検索」の概念をカバーしていないようです。 たとえば、求人検索サイトをサポートする一連のWebサービスの設計では、次の要件があります。 個々の求人広告を取得する GETへdomain/Job/{id}/ 求人広告を作成 POSTへdomain/Job/ 求人広告の更新 PUT todomain/Job/ 求人広告の削除 DELETEへdomain/Job/ 「Get All Jobs」も簡単です。 GETへdomain/Jobs/ しかし、仕事の「検索」はこの構造にどのように分類されますか？ あなたは可能性があり、それは「リストコレクション」のバリエーションの主張として実装します。 GETへdomain/Jobs/ ただし、検索は複雑になる可能性があり、長いGET文字列を生成する検索を作成することは完全に可能です。つまり、ここでSOの質問を参照すると、約2000文字よりも長いGET文字列の使用に問題があります。 例として、ファセット検索があります-「ジョブ」の例を続けます。 「テクノロジー」、「役職」、「規律」、およびフリーテキストキーワード、就業年齢、場所、給与などのファセットでの検索を許可できます。 流動的なユーザーインターフェイスと多数のテクノロジと役職により、検索に多数のファセットの選択肢を含めることが可能です。 この例をジョブではなくCVに微調整すると、さらに多くのファセットがもたらされ、100個のファセットが選択された検索、または50文字の長さ（たとえば役職、大学名、雇用者名）。 そのような状況では、検索データが正しく送信されるようにするために、PUTまたはPOSTを移動することが望ましい場合があります。例えば： POSTへdomain/Jobs/ しかし意味的には、これはコレクションを作成するための命令です。 これを検索の作成として表現することもできます。 POSTへdomain/Jobs/Search/ または（以下のburninggrammaで示唆されているように） POSTへdomain/JobSearch/ 意味的には理にかなっているように思えるかもしれませんが、実際には何も作成しておらず、データを要求しています。 したがって、セマンティック上はGETですが、GETは必要なものをサポートすることを保証されていません。 ですから、質問は-可能な限りRESTfulなデザインを忠実に保ちながら、HTTPの制限内に収まるようにしながら、検索に最適なデザインは何ですか？

137 design  rest  api-design  http-request 

モバイルアプリケーションとAPIの量は日々増加しているため、REST APIを保護するための最適なセキュリティソリューションを探しています。 私はさまざまな認証方法を試しましたが、まだいくつかの誤解があるため、より経験豊富な誰かのアドバイスが必要です。 このすべてを理解する方法を教えてください。何か間違って理解した場合は、お知らせください。 REST APIが一般にWEBと同様にステートレスである限り、各リクエスト（cookies、token ....）で認証データを送信する必要があります。ユーザーを認証するために広く使用されている3つのメカニズムを知っています HTTPSを使用したトークン。私はこのアプローチを何度も使用しましたが、HTTPSで十分です。ユーザーが正しいパスワードとログインを提供すると、応答としてトークンを受け取り、それを以降のリクエストに使用します。トークンはサーバーによって生成され、保存されます。たとえば、ユーザー情報が保存される別のテーブルまたは同じテーブルに保存されます。そのため、各リクエストサーバーで、ユーザーがトークンを持っているかどうかを確認します。トークンがデータベース内と同じである場合。すべてが非常に簡単です。 JWTトークン。このトークンは自己記述的であり、トークン自体に関するすべての必要な情報が含まれています。このトークンは秘密キーワードを使用してサーバーによって生成（署名）されるため、ユーザーは有効期限やその他の要求などを変更できません。これも明らかです。しかし、個人的には、トークンを無効にする方法の1つの大きな問題です。 OAuth 2.サーバーとクライアント間で直接通信が確立される場合、このアプローチを使用する必要がある理由がわかりません。私の知る限り、OAuthサーバーは、他のアプリケーションがパスワードとログインを保存せずにユーザー情報にアクセスできるように、制限されたスコープでトークンを発行するために使用されます。これは、ユーザーが何らかのページでサインアップしたい場合、ソーシャルネットワークにとって優れたソリューションです。サーバーは、たとえばtwitterやfacebookからユーザー情報を取得する許可を要求し、登録フィールドにユーザーデータなどを入力できます。 オンラインストアのモバイルクライアントを検討してください。 最初の質問は、最初のタイプのトークンよりもJWTを好むべきですか？モバイルクライアントでログイン/ログアウトユーザーが必要な場合、トークンをどこかに格納する必要があります。JWTの場合、ログアウト時にトークンを無効にする必要があります。トークンを無効化するには、無効なトークンリスト（ブラックリスト）を作成する方法があります。うーん。テーブル/ファイルのサイズは、トークンがテーブルに保存されてユーザーに関連付けられ、ログアウト時に削除された場合よりもはるかに大きくなります。 それでは、JWTトークンの利点は何ですか？ OAuthに関する2番目の質問は、サーバーと直接通信する場合に使用する必要がありますか？クライアントとサーバー間のもう1つのレイヤーの目的はトークンの発行のみですが、通信はoauthサーバーではなくメインサーバーと行われます。私が理解しているように、OAuthサーバーは、ユーザーの個人情報にアクセスするためのサードパーティアプリのアクセス許可（トークン）を付与する責任があります。しかし、私のモバイルクライアントアプリケーションはサードパーティではありません。

104 security  rest  api  oauth  https 

REST APIが信頼できるクライアント、私の場合は自分のモバイルアプリケーションによって生成されたリクエストにのみ応答することを確認するにはどうすればよいですか？他のソースからの不要なリクエストを防ぎたい。ユーザーがシリアルキーなどを入力するのは望ましくありません。これは、バックグラウンドで、インストール時に、ユーザーの操作なしで発生するはずです。 私の知る限り、HTTPSは、通信相手のサーバーが本人であることを検証することのみを目的としています。もちろん、データを暗号化するためにHTTPSを使用します。 これを達成する方法はありますか？ 更新： ユーザーは読み取り専用のアクションを実行できますが、ユーザーはログインする必要がありませんが、ユーザーがログインする必要がある書き込みアクションも実行できます（アクセストークンによる認証）。どちらの場合も、信頼できるモバイルアプリケーションからのみのリクエストにAPIが応答するようにします。 APIは、モバイルアプリケーションを介して新しいアカウントを登録するためにも使用されます。 更新2：これには複数の答えがあるように見えますが、正直なところ、どれに答えとしてフラグを立てるべきかわかりません。できると言う人もいれば、できないと言う人もいます。

96 security  rest  mobile 

最近、私はRESTに慣れることに興味を持ち始めました。RESTのwikiエントリを読んでみましたが、助けにはなりませんでした。誰かが簡単な英語で説明できるなら、それは本当にありがたいです（不必要な技術用語はありません） RESTとは Webアーキテクチャエコシステムで占める位置 プロトコルとどの程度緊密に（または緩く）結合されているか。 RESTの代替とは何か、RESTはそれらとどのように比較されますか。 1つまたは2つのパラグラフでこれに答えることができない場合があることを理解しています。その場合、関連リンクが高く評価されます。

84 rest 

RESTful Webサービスを実装していますが、利用可能なアクションの1つはになりますreload。設定、キャッシュなどを再ロードするために使用されます。 GETこのような単純なURIから始めました${path}/cache/reload（パラメーターは渡されず、URIのみが呼び出されます）。GETリクエストでデータを変更しないでください。 RESTful Webサービスでアクション/コマンドを呼び出すために使用する正しい動詞はどれですか？ リロードは、独自のキャッシュ/構成/などをリロードするREST Webサービスのコマンドです。クライアントに情報を返すメソッドではありません。 おそらく私がやろうとしていることはRESTではありませんが、それでもこの方法で行う必要があるものです。このreloadメソッドは、アプリケーションの範囲内で意味のある実際の例に過ぎず、ほとんどの回答はそれに焦点を当てていますが、実際には、CRUDを実行しないがデータ/データを変更するアクションをトリガーする動詞を知る必要がありました状態。 Stack Overflowでこの詳細な回答を見つけました。件名：https ://stackoverflow.com/questions/16877968/

80 rest  rpc 

特に、ユーザーがWeb APIで許可/認証された操作を実行する方法に興味があります。 認証CookieはRESTの哲学と互換性がありますか？

77 web-applications  web-services  rest 

次のような3つのリソースがあるとします。 Grandparent (collection) -> Parent (collection) -> and Child (collection) 上記は、これらのリソース間の関係を示しています。各祖父母は、1つまたは複数の親にマップできます。各親は、1つまたは複数の子にマップできます。子リソースに対する検索をサポートする機能が必要ですが、フィルター条件があります。 クライアントが祖父母へのID参照を渡した場合、その祖父母の直接の子孫である子供に対してのみ検索したいです。 クライアントが親へのID参照を渡した場合、親の直接の子孫である子に対してのみ検索したいです。 私はそのようなことを考えました： GET /myservice/api/v1/grandparents/{grandparentID}/parents/children?search={text} そして GET /myservice/api/v1/parents/{parentID}/children?search={text} 上記の要件に対して、それぞれ。 しかし、私はこのようなこともできます： GET /myservice/api/v1/children?search={text}&grandparentID={id}&parentID=${id} この設計では、クライアントにクエリ文字列のいずれかを渡すことができます：grandparentIDまたはparentIDのいずれかで、両方ではありません。 私の質問は： 1）どのAPI設計がよりRESTfulであり、その理由は何ですか？意味的には、同じ意味であり、同じように動作します。URIの最後のリソースは「子」であり、事実上、クライアントが子リソースを操作していることを意味します。 2）クライアントの観点からの理解可能性、およびデザイナーの観点からの保守性という点で、それぞれの長所と短所は何ですか。 3）リソースの「フィルタリング」以外に、実際に使用されるクエリ文字列は何ですか？最初の方法を使用する場合、フィルターパラメーターは、クエリ文字列パラメーターではなく、パスパラメーターとしてURI自体に埋め込まれます。 ありがとう！

73 design  rest  api 

StackExchangeは初めてですが、あなたが私を助けることができると思いました。 レガシーJSPソリューションを置き換える新しいJava Enterpriseアプリケーションを作成しています。多くの変更により、UIとビジネスロジックの一部は完全に再考され、再実装されます。 Java EEの標準であるJSFが最初に考えられました。最初は良い印象がありました。しかし今、私は機能的なプロトタイプを実装しようとしていますが、それを使用することに関して本当に深刻な懸念があります。 まず第一に、それは私が今まで見た中で最悪で最も雑然とした無効な擬似HTML / CSS / JSミックスを作成します。ウェブ開発で学んだすべてのルールに違反しています。さらに、レイアウト、デザイン、ロジック、サーバーとの通信など、決して緊密に結合されるべきではないものが一緒に投げられます。CSSでスタイリングしたり、UIキャンディー（構成可能なホットキー、ドラッグアンドドロップウィジェットなど）を追加したりなど、この出力を快適に拡張する方法がわかりません。 第二に、それはあまりにも複雑です。その複雑さは際立っています。あなたが私に尋ねると、それは基本的なウェブ技術の貧弱な抽象化であり、最終的には不自由で役に立たない。私にはどんな利点がありますか？考えてみれば、なし。何百ものコンポーネント？さらに、数万のHTML / CSSスニペット、数万のJavaScriptスニペット、および数千のjQueryプラグインが表示されます。これは本当に多くの問題を解決します-JSFを使用しない場合はありません。または、フロントコントローラーパターン。 そして最後に、2年後にはやり直さなければならないと思います。最初のGUIモックアップをすべて実装する方法がわかりません（さらに、チームにはJSFエキスパートがいません）。どういうわけか一緒にハッキングできたかもしれません。そして、さらにあります。ハックをハッキングできると確信しています。しかし、いつかは行き詰まってしまいます。サービス層より上のすべてのものがJSFを制御しています。そして、最初からやり直す必要があります。 私の提案は、JAX-RSを使用してREST APIを実装することです。次に、クライアント側のMVCでHTML5 / Javascriptクライアントを作成します。（またはMVCのフレーバー..）ところで。部分的なAndroidフロントエンドも開発しているため、とにかくREST APIが必要になります。 私は、JSFが今日の最良のソリューションであることを疑っています。インターネットが進化しているので、なぜこの「レーキ」を使用する必要があるのか​​わかりません。 さて、賛否両論とは何ですか？JSFを使用しないという点を強調するにはどうすればよいですか？私の提案よりもJSFを使用する長所は何ですか？

64 java  javascript  web-applications  rest 

最近、アプリケーション状態のエンジン（HATEOAS）としてのハイパーメディアについて読んでいます。これは、Web APIを「真にRESTful」とする制約です。基本的に、現在の状態から可能な遷移へのすべての応答にリンクを含めることになります。 HATEOASが私の理解に基づいていることを説明させてください。何かを見逃した場合は、訂正してください。 / GET: { "_links": { "child": [ { "href": "http://myapi.com/articles", "title": "articles" } ] } } /articles?contains=HATEOAS GET: { "_items": [ { "uri": "http://myapi.com/articles/0", "title": "Why Should I Care About HATEOAS?" }, { "uri": "http://myapi.com/articles/1", "title": "HATEOAS: Problem or Solution?" } ], "_links": { "self": { "href": …

61 rest  http  hateoas 

私はRESTful APIの末尾のスラッシュをどうするかについて議論していました。 犬と呼ばれるリソースと、個々の犬用の下位リソースがあるとします。したがって、次のことができます。 GET/PUT/POST/DELETE http://example.com/dogs GET/PUT/POST/DELETE http://example.com/dogs/{id} しかし、次の特別な場合はどうしますか： GET/PUT/POST/DELETE http://example.com/dogs/ 私の個人的な見解では、これはid =で個々のdogリソースにリクエストを送信するということnullです。この場合、APIは404を返すはずです。 他の人は、リクエストがdogsリソースにアクセスしている、つまり末尾のスラッシュが無視されると言います。 誰もが決定的な答えを知っていますか？

60 api  rest  http 

私はRESTfull APIを構築する予定ですが、私の頭の中にいくつかの問題を引き起こしているいくつかのアーキテクチャ上の質問があります。クライアントにバックエンドビジネスロジックを追加することは、ビジネスロジックが急速に変化する可能性があるため、複数のクライアントプラットフォームの更新をリアルタイムで維持するのが難しいため、回避したいオプションです。 リソースとして記事（api / article）があるとしましょう。発行、非公開、アクティブ化、非アクティブ化などのアクションをどのように実装する必要がありますか？ 1）api / article / {id} / {action}を使用する必要があります。リモートロケーションへのプッシュや複数のプロパティの変更など、多くのバックエンドロジックがそこで発生する可能性があるためです。おそらくここで最も難しいことは、更新のためにすべての記事データをAPIに送り返す必要があり、マルチユーザーの作業を実装できなかったことです。たとえば、エディターは5秒前のデータを送信し、他のジャーナリストが2秒前に行った修正を上書きすることができます。また、記事を公開している人はコンテンツの更新とはまったく関係がないため、これをクライアントに説明する方法はありません。 2）新しいリソースの作成もオプションapi / article- {action} / idですが、返されるリソースはarticle- {action}ではなく、これが適切かどうかわからない記事になります。また、サーバー側のコード記事クラスでは、両方のリソースで実際の作業を処理していますが、これがRESTfull思考に反するかどうかはわかりません どんな提案も歓迎します。

59 api  rest 

例について説明します 。パン屋のAPIの作成を開始します。APIを使用すると、ユーザーはを使用して自家製ミントチョコレートチップクッキーなどのベーキング製品のカタログを検索できますapi.examplebakery.com/search?q=.....。 誰かがこれを使って名前の付いた製品を探しますが、pineapple-banana flavoured cookies明らかに結果が見つかりません。 これはエラーとして返されるべきですか？検索は失敗せず、APIが検索し、Cookieが見つからないという結論に達しました。404APIが実際に見つかったため、APIはを返すべきではありません。

52 rest  http-response 

最後に、SOAPベースのサービスに出くわしたのは、2013年に金融会社でインターンシップを行っていたときです。それが、ITでのキャリアを始めたときでした。私のエンジニアリングコースの1つで、SOAPについての学習資料を持っていたことを覚えています。それ以外では、私はキャリアの中でSOAPをあまり使用していません。 「SOAPとRESTの違い」という質問が最近のインタビューの1つで出てきたので、私はこれを尋ねています。私が知っていること（およびGoogleで発見したこと）から、SOAPは、ビジネスロジックに密接に関連する情報交換のためにクライアントとサーバーを密結合したプロトコルです。一方、RESTはデータ転送のためのより柔軟なステートレスアーキテクチャです。 SOAPとRESTのこの違いについて間違っている場合、誰かが私を修正してくれますか？また、SOAPの現在の重要性は何ですか？人々はまだ新しいSOAPベースのAPIを開発していますか、それとも今はほとんどレガシーですか？

51 rest  api  web-services  soap 

現在、Slim Frameworkを使用してソーシャルネットワーク用のAPIをコーディングしています。私の質問は、json構造に返す行がない場合のベストプラクティスは何ですか？ この呼び出し/ v1 / get / moviesがテーブルmovie namesから2行を返すとしましょう： [ {"name": "Ghostbusters"}, {"name": "Indiana Jones"} ] しかし、それから/ v1 / get / booksを呼び出すと、そのテーブルには行がありません。空の構造を返すだけですか？ [ ] ...または、メッセージとエラーコードの方が良いでしょうか？ [ "errors": { "message": "no matches found", "code": 134 } ] どちらが良い方法ですか？（APIはiOSおよびAndroidアプリで使用されます）ありがとう！

50 programming-practices  rest  api-design  json