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

私は、REST APIがHATEOASに準拠し、すべてのリチャードソンの成熟度レベル（http://martinfowler.com/articles/richardsonMaturityModel.html）を実装する必要があると考える一部の上級チームメンバーが信じているプロジェクトに参加しています！ AFAIKのほとんどのREST実装はHATEOASに準拠していないため、より多くの人がそれを行わないのには十分な理由があるはずです。追加された複雑さ、フレームワークの欠如（サーバー側とクライアント側）、パフォーマンスの懸念などの理由を考えることができます... どう思いますか？現実世界のプロジェクトでHATEOASの経験はありますか？

110 rest  hateoas 

保存したクレジットカードを使用した注文など、ユーザーとのさまざまなやり取りを処理するRESTful APIを作成しています。 注文が成功した場合は200 OKを返し、注文リクエストの形式が無効または無効な場合は400 Bad Requestを返します。しかし、注文の実際の処理中に問題が発生した場合はどうすればよいですか？ ユーザーリソースのサーバーへのクライアントPOSTS注文。ユーザーが存在しない場合は、404 Not Foundが返されます。 注文の形式と情報が検証されます。無効な場合、400 Bad Requestが返されます。 注文が処理されました。注文が成功すると、注文に対して201 Createdが返されます。予期しないエラーが発生した場合、500サーバーエラーが返されます。 最後のステップは問題です。他の理由で注文が完了しなかった場合はどうすればよいですか？考えられるシナリオは次のとおりです。 商品は売り切れです ユーザーの最大注文数に達しました クレジットカード決済失敗（資金不足等） これは、400と500のどちらにも適しているとは思えません。適切なコードがない場合、400と見なすことができます。ビジネスルールによれば、リクエストは無効でした。正確ではないようです。 編集：同じトピックに関するこの既存のディスカッションも見つかりました。そこにあるすべての回答は、このタイプの違反にステータスコードを使用することを示しているようです。400、409、または422の拡張機能を使用することについての議論もあります。

109 http  rest  http-status-codes 

私はかなりベースから外れているかもしれませんが、私は午後中ずっとこの休憩PHPフレームワークチュートリアルでcurl postコマンドを実行しようとしています。私が理解していないのは、PHPが私のPOSTをどのように解釈することになっているのか、それは常に空の配列として現れることです。 curl -i -X POST -d '{"screencast":{"subject":"tools"}}' \ http://localhost:3570/index.php/trainingServer/screencast.json （そこのスラッシュは私を馬鹿のように見せないようにするだけですが、PHP 5.2を使用してこれをWindowsから実行しました。Linuxcurlと同じバージョンのLinuxサーバーでも試してみました） それはかなり簡単に見えるので、私が見逃しているものがあるに違いありません。投稿は正しく解釈されません。もしそうなら、すべてがうまく機能します。 これは私が返すものです： HTTP / 1.1 409の競合 日付：2009年5月1日（金）22:03:00 GMT サーバー：Apache / 2.2.8（Win32）PHP / 5.2.6 X-Powered-By：PHP / 5.2.6 Transfer-Encoding：チャンク Content-Type：text / html; charset = iso-8859-1 {"スクリーンキャスト"：{"id"：null、 "subject"：null、 "body"：null、 "dataUrl"：null、 "dataMedium"：null、 "createdOn"：null、 "author"：null}}

108 php  rest  post 

関連： なぜWebサービスの代わりにRESTを使用するのですか？ SOAPまたはREST（RESTfulな方法でHTTP / XMLを意味する）を使用してWebサービスを実装するかどうかを決定するとき、何に注意し、何を考えればよいですか？これは1つのサイズですべてに適合するわけではないので、どの方法を使用するかを選択するにはどうすればよいでしょうか。

108 web-services  rest  wsdl 

パスワードをリセットするためのRESTfulリソースを構築する適切な方法は何ですか？ このリソースは、パスワードを紛失したり忘れたりした場合のパスワード再設定者になることを目的としています。古いパスワードを無効にし、パスワードを電子メールで送信します。 私の2つのオプションは次のとおりです。 POST /reset_password/{user_name} または... POST /reset_password -Username passed through request body 私はリクエストがPOSTであるべきだと確信しています。適切な名前を選択したことに自信が持てません。また、user_nameをURLとリクエスト本文のどちらを介して渡す必要があるかはわかりません。

107 rest  password-recovery 

Postman（Chromeで開かないもの）があり、生のjsonを使用してPOSTリクエストを実行しようとしています。 「ボディ」タブで、「raw」を選択し、「JSON（アプリケーション/ json）」に次のボディを設定しました。 { "foo": "bar" } ヘッダーには1があります Content-Type: application/json PHP側ではprint_r($_POST);、今のところやっているだけで、空の配列を取得しています。 私がjQueryを使用して行う場合： $.ajax({ "type": "POST", "url": "/rest/index.php", "data": { "foo": "bar" } }).done(function (d) { console.log(d); }); 私は期待通りになっています： Array ( [foo] => bar ) では、なぜそれがPostmanで機能しないのですか？ 郵便配達のスクリーンショット： およびヘッダー：

107 php  json  rest  postman 

基本認証を使用して承認リクエストを送信する必要があります。jqueryを使用してこれを正常に実装しました。ただし、401エラーが発生すると、基本認証ブラウザのポップアップが開き、jquery ajaxエラーコールバックが呼び出されません。

107 javascript  jquery  rest  basic-authentication 

を呼び出しGETてユーザーのリストを取得したいとしますapi/usersが、現時点ではテーブルが切り捨てられているため、ユーザーはいないとします。このシナリオの適切な応答は何ですか：404または204？

106 api  http  rest 

非CRUD操作をRESTfulサービスに追加する「RESTful」な方法は何ですか？次のようなレコードへのCRUDアクセスを許可するサービスがあるとします。 GET /api/car/123 <- Returns information for the Car object with ID 123 POST /api/car <- Creates a new car (with properties in the request) PUT /api/car/123 <- Updates car 123 (with properties in the request) DELETE /api/car/123 <- Deletes car 123 POST /api/car/123/wheel/ <- Creates a wheel and associates …

106 web-services  rest 

閉まっている。この質問はスタックオーバーフローのガイドラインを満たしていません。現在、回答を受け付けていません。 この質問を改善してみませんか？Stack Overflowのトピックとなるように質問を更新します。 4年前休業。 この質問を改善する Rest APIサーバー（Symfony PHPではWebサービス内にあります）をScalaに移動することを考えています：速度、オーバーヘッドがない、CPUが少ない、コードが少ない、スケーラビリティーなど。いくつかまでScalaを知りませんでした数日前ですが、Scalaブックとすべてのブログ投稿および質問で、最近学んでいることを楽しんでいます（それほど醜くはありません！） 次のオプションがあります。 Rest APIサーバーを一から構築する Scalatraのような小さなScala Webフレームワークを使用する リフトを使用する HTTPリクエスト、JSON出力、MySQL（データ）、OAuth、Memcache（キャッシュ）、ログ、ファイルのアップロード、統計（おそらくRedis）。 あなたは何をお勧めします？

105 api  rest  scala  lift 

このようなREST GET APIの推奨タイムスタンプ形式は次のとおりです。 http://api.example.com/start_date/{timestamp} 実際の日付形式はYYYY-MM-DDThh:mm:ssZ、UTC時間などのISO 8601形式にする必要があると思います。 次のように、ハイフンとコロンのないISO 8601バージョンを使用する必要があります。 http://api.example.com/start_date/YYYYMMDDThhmmssZ または、たとえばbase64エンコーディングを使用して、ISO 8601形式をエンコードする必要がありますか？

105 http  url  rest  date  get 

Spring BootのWebサイトでRESTコントローラーの例を採用しようとしています。残念ながら、localhost:8080/itemURL にアクセスしようとすると、次のエラーが発生します。 { "timestamp": 1436442596410, "status": 404, "error": "Not Found", "message": "No message available", "path": "/item" } POM： <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>SpringBootTest</groupId> <artifactId>SpringBootTest</artifactId> <version>0.0.1-SNAPSHOT</version> <properties> <javaVersion>1.8</javaVersion> <mainClassPackage>com.nice.application</mainClassPackage> <mainClass>${mainClassPackage}.InventoryApp</mainClass> </properties> <build> <plugins> <plugin> <artifactId>maven-compiler-plugin</artifactId> <version>3.3</version> <configuration> <source>${javaVersion}</source> <target>${javaVersion}</target> </configuration> </plugin> <!-- Makes the Spring Boot app executable …

104 java  rest  spring-boot 

私はReST APIのバージョン管理戦略について調べてきましたが、それらのどれも対処していないように見えるのは、基盤となるコードベースの管理方法です。 我々は、APIへの変更を壊すの束を作っているとしましょう-例えば、それは別の返すように私たちのお客様のリソースを変更forenameし、surname代わりに、単一のフィールドnameのフィールド。（この例では、関連する概念を理解するのは簡単なので、URLバージョン管理ソリューションを使用しますが、質問はコンテンツネゴシエーションまたはカスタムHTTPヘッダーにも同様に適用できます） これで、にエンドポイントがhttp://api.mycompany.com/v1/customers/{id}あり、別の互換性のないエンドポイントがにありますhttp://api.mycompany.com/v2/customers/{id}。私たちはまだv1 APIのバグ修正とセキュリティ更新をリリースしていますが、新機能の開発はすべてv2に焦点を合わせています。APIサーバーへの変更をどのように記述、テスト、およびデプロイしますか？私は少なくとも2つの解決策を見ることができます： v1コードベースのソース管理ブランチ/タグを使用します。v1とv2は個別に開発およびデプロイされ、両方のバージョンに同じバグ修正を適用するために必要に応じてリビジョンコントロールマージが使用されます。これは、以前のバージョンをサポートしながらメジャーな新しいバージョンを開発するときにネイティブアプリのコードベースを管理する方法と同様です。 コードベース自体にAPIバージョンを認識させると、v1の顧客表現とv2の顧客表現の両方を含む単一のコードベースが作成されます。デプロイメントの問題ではなく、ソリューションアーキテクチャの一部としてバージョン管理を扱います。おそらく名前空間とルーティングのいくつかの組み合わせを使用して、要求が正しいバージョンで処理されるようにします。 ブランチモデルの明らかな利点は、古いAPIバージョンを削除するのが簡単であることです。適切なブランチ/タグのデプロイを停止するだけですが、複数のバージョンを実行している場合、ブランチ構造とデプロイパイプラインが非常に複雑になる可能性があります。「統一されたコードベース」モデルはこの問題を回避しますが、（不要だと思いますか？）不要になったリソースとエンドポイントが不要になったときにコードベースから削除することをはるかに難しくします。単純な正解はありそうもないので、これはおそらく主観的ですが、複数のバージョンにわたって複雑なAPIを維持している組織がこの問題をどのように解決しているかを知りたいと思います。

104 rest  versioning  api-versioning 

プロジェクト用のREST APIを構築しています。特定のユーザーの情報を取得するためのAPIは次のとおりです。 api.com/users/[USER-ID] クライアントがユーザーIDのリストを渡すことも許可したいと思います。RESTfulでユーザーIDのリストを取得するようにAPIを構築するにはどうすればよいですか？

103 api  rest 

これは概念的な質問です。 RESTful Webサービスに対するログインアクションをサポートする必要があるクライアント（モバイル）アプリケーションがあります。WebサービスはRESTfulであるため、これはクライアントがユーザーからユーザー名/パスワードを受け入れ、そのユーザー名/パスワードをサービスで検証し、その後のすべての要求でそのユーザー名/パスワードを送信することを覚えていることになります。 このWebサービスの他のすべての応答は、JSON形式で提供されます。 問題は、特定のユーザー名/パスワードが有効かどうかを単に確認するためにWebサービスにクエリを実行する場合、Webサービスが常にJSONデータで応答して成功または失敗を通知するか、または適切な資格情報とHTTPでHTTP 200を返すかです。資格情報が不適切な場合は401。 私が尋ねる理由は、他の一部のRESTfulサービスは、資格情報が有効かどうかを尋ねているだけの場合でも、不正な資格情報に401を使用するためです。ただし、401応答についての私の理解は、それらは有効な資格情報なしではアクセスできないはずのリソースを表すということです。ただし、ログインリソースの目的はすべて、資格情報が有効かどうかを通知することなので、ログインリソースはだれでもアクセスできる必要があります（SHOULD）。 別の言い方をすれば、次のようなリクエストのようです。 myservice.com/this/is/a/user/action 不正な認証情報が提供された場合は401を返します。しかし、次のようなリクエスト： myservice.com/are/these/credentials/valid その特定のURL（要求）は有効な資格情報の有無にかかわらず許可されるため、401を返すことはありません。 これについて、正当化された意見がいくつかあります。これを処理する標準的な方法は何ですか？これを論理的に適切に処理する標準的な方法は何ですか？

103 http  rest  login  http-response-codes