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

API Gatewayについて読むと、毎回出てくるものの1つは、API Gatewayが複数のエンドポイントからの結果を集約する場所であるということです。それは本当にいいですね。ただし、AWS API Gateway、Kongo、Netflix Zuulなどの多くの一般的なAPI Gatewayソリューションは、このような機能をサポートしていません。ハックするか、カスタムフィルターを自分で実装する必要があります。 集約は悪い習慣と見なされていますか？複数のエンドポイントから結果を返す方法

15 rest  api  microservices 

主に単一のクライアントのニーズを満たすことを目的としたRESTful APIを設計しています。非常に特殊な状況のため、このクライアントはできるだけ少ないリクエストを作成する必要があります。 APIは、リクエストのAccept-Languageヘッダーを介してi18nを処理します。これは、利用可能なすべてのロケールで単一のエンドポイントへの要求の応答をクライアントが保存する必要がある1つの機能を除き、クライアントが行う必要があるすべてのことに対して機能します。 クライアントが単一のリクエストでこれらすべての情報を取得できるように、一貫性のある適切に構造化されたRESTful API設計を壊さずに、何らかの方法でAPIを設計できますか？ これまで検討してきたオプション： Accept-Languageヘッダーに複数のロケールを含めることを許可し、応答で要求されたすべてのロケールのローカライズバージョンを追加します。各ロケールはキーとしてISO 639-1言語コードで識別されます。 そのエンドポイントに「？all_languages = true」パラメーターのようなものを作成し、そのパラメーターが存在する場合、応答で使用可能なすべてのロケールのローカライズバージョンを返します。 （上記のいずれも機能しない場合）ローカライズされたすべてのバージョンをクライアントから取得するために複数のリクエストを作成します。 どれが最良の選択肢ですか？

15 rest  api  api-design  http 

私のREST実装は、次の構造を持つJSONでエラーを返します。 { "http_response":400, "dev_message":"There is a problem", "message_for_user":"Bad request", "some_internal_error_code":12345 } プロパティ（dev_message、message_for_user、some_internal_error_code）に必要な値を渡し、それらを返すことができる特別な応答モデルを作成することをお勧めします。コードでは、これは次のようになります。 $responseModel = new MyResponseModel(400,"Something is bad", etc...); このモデルはどのように見えるべきですか？メソッドを実装する必要があります。たとえば、テキスト情報のみを渡すsuccessResponse（）で、コードはデフォルトで200になりますか？これにこだわっています。これは私の質問の最初の部分です。このモデルを実装する必要がありますか、これは良い練習ですか？今のところ、コードから直接配列を返すだけだからです。 2番目の部分は、エラーコードシステムについてです。エラーコードについては、ドキュメントで説明します。しかし、私が遭遇している問題はコードにあります。エラーコードを管理する最良の方法は何ですか？それらをモデル内に記述する必要がありますか？または、これを処理するための別のサービスを作成する方が良いでしょうか？ 更新1 応答用のモデルクラスを実装しました。これはGregの答えと似ていますが、同じロジックですが、さらに、モデルに記述されたエラーをハードコーディングしました。ここでは、次のようになります。 class ErrorResponse { const SOME_ENTITY_NOT_FOUND = 100; protected $errorMessages = [100 => ["error_message" => "That entity doesn't exist!"]]; ...some code... } なぜこれをしたのですか？そして何のために？ コードでは格好いいです： return new ErrorResponse(ErrorResponse::SOME_ENTITY_NOT_FOUND ); …

15 php  mvc  rest  api 

私は.NET 4.5 C＃Web API RESTfulソリューションを構築していますが、ドメイン駆動設計を使用して設計されたソリューションのプロジェクトソリューションが正しいか、賢明であるか（または十分ですか）を教えてください。 ソリューションは6つのプロジェクトに分割されました。 /ベース （何にも参照されない） Webプロジェクトは、ソリューションと外部の世界との間のインターフェースを形成します。Web APIコントローラーが含まれています。要求オブジェクトから値を収集し、BizApiレイヤーに作業を依頼する以外のロジックはほとんど含まれていません。 /Biz.Api （ベースで参照]） ドメインサービスを提供し、/ Baseインターフェイスプロジェクトが/Biz.Domainプロジェクトのドメインビジネスロジックオブジェクトにアクセスできるようにします。 /Biz.Domain （Biz.Apiが参照） Biz.Apiレイヤーのドメインクラスを提供します。これらは、メモリ内のビジネスのデータを操作するメソッドを提供します。 /Dal.Db （Biz.Apiが参照） データベースリポジトリレイヤー。データベースにアクセスし、返されたデータを/ Interfacesレイヤーで定義された内部DTOにマップします。 /Dal.Services （Biz.Apiが参照） Webサービスなどの外部の依存関係にプロキシレイヤーを提供し、返されたデータを/ Interfacesプロジェクトで定義された内部DTOにマップします。 /インターフェース （上記のほとんどのプロジェクトで参照） ソリューションにデータを渡すためのDTOクラスと、IoCなどのコントラクトを定義するC＃インターフェイスが含まれています。

15 c#  rest  domain-driven-design 

私はRest APIを書いていますが、さまざまなバージョンのサポートをどのように処理するのが最善か疑問に思っています。これにより、URIをV2またはV3として定義する方法を意味するのではなく、必要なコードを構成する方法を意味します。 同時に複数のバージョンをサポートします。V1＆V2＆V3 URIは同時に有効でなければなりません。一度にサポートされる量を制限するためにV4が来るとV1を廃止します。 可能な限りコードの重複を避ける 他のバージョンに影響を与えることなく、簡単な変更をバージョンに簡単に追加できます 取れるアプローチはほとんどないと思われます。 Gitを使用してバージョンを制御し、異なるバージョンのブランチを使用します（古いバージョンでは、基本的に新しい開発作業は行われません）。これは、最新バージョンのみがコードに含まれているため、コードの重複がないことを意味しますが、以前のバージョンは、廃止されるまで新しいバージョンのDBで動作する必要があります。 各バージョンが同じアプリケーションで処理され、完全に別個のコードパスを持つようにコードを複製しますが、これは多くの複製を意味します バージョン間で多くのコードを再利用しますが、1つのバージョンを変更すると以前のバージョンに影響を与える可能性が高くなるため、メンテナンスが難しくなります すべてのオプションには独自の問題があるように見えるため、この問題に対処するためのベストプラクティスはありますか？

15 rest  asp.net-mvc-web-api 

データベースをアプリケーションに追加/更新するための挿入（i等ではなく、POST）および更新（PUT、べき等）の要求を許可するREST APIを構築しています。 POST（挿入）操作の応答でクライアントに返送するデータに関して、標準やベストプラクティスがあるかどうか疑問に思っています。少なくともレコードID値を返送する必要があります（たとえば、新しいレコードはレコード＃1234です）。 オブジェクト全体で応答する必要がありますか？（たとえば、「GET / object_type / 1234」リクエストから返される本質的に同じ応答） 新しいID値のみで応答する必要がありますか？（たとえば、「{id：1234}」。つまり、レコード全体を取得する場合は、追加のHTTP GETリクエストを実行してレコード全体を取得する必要があります） 完全なオブジェクトのURLを指すリダイレクトヘッダー？ 完全に何か他のもの？

15 rest 

正しく理解できれば、RESTはWebのアーキテクチャの記述モデルとしてRoy Fieldingによって正式化されました。AFAIK FieldingはRESTが良いと主張したわけではなく、Webの事実上のアーキテクチャを説明しているだけでした。Webはこの時点ですでに非常に成功した分散ハイパーテキストシステムを証明しているため、この種のRESTは、主に人間がナビゲートして消費する分散ハイパーメディアのドメインの成功したアーキテクチャとして検証されます。 REST Webサービスは、RESTアーキテクチャをAPIに適用することで作成されました。しかし、実際にはRESTがこのドメインに望ましいアーキテクチャであると考える理由はありますか？より具体的には、HATEOASがマシンツーマシン通信の有益な設計原則であるという証拠はありますか？ 私の懸念は、よく知られているコンテンツタイプ（HTML、画像、ビデオなど）がほとんどなく、クライアントがそれらを使用する方法を知っているため、HATEOASはハイパーメディアに意味があることです。ただし、APIの場合、コンテンツタイプは非常に具体的であり、クライアントがそれらを消費するように特別にプログラムされている場合にのみ、クライアントが意味のある方法で消費できます。クライアントにURLを返すだけでは、クライアントは指定されたリソースを消費できません。

15 rest  hateoas 

マイクロサービスアーキテクチャに関する多くの記事を読みましたが、AMQPまたはRESTをいつ使用すべきか疑問に思いました。 サービス間の疎結合は良いことであり、その場合AMQPが良い選択であるように思えます。しかし、AMQPを使用する場合、これはRESTエンドポイントが不要になることを意味します（ただし、HATEOASコンセプトが失われることを意味します）。 しかし、RESTは本当に私のサービスを構築するのに良い方法ですか？原因エンドポイントを使用しません...この場合、一方が他方より優れていますか？ いつどちらを使用すればよいですか？

15 rest  api  web-services  microservices 

トーナメントとスケジュールのためのシンプルなRESTfulサービスを開発しています。JSONボディを含むPOSTリクエストを通じてトーナメントが作成されると、トーナメントはに挿入さBiMapれ、DAO実装で次のように宣言されます。 private BiMap<String, Tournament> tournaments = Maps.synchronizedBiMap(HashBiMap.create()); トーナメントが作成されると、それに関連付けられた文字列IDが返されるので、ユーザーはそのトーナメントを将来参照することができます。彼/彼女は次のリクエストを実行して新しいトーナメントから情報を得ることができます： GET http://localhost:8080/eventscheduler/c15268ce-474a-49bd-a623-b0b865386f39 しかし、そのようなIDのトーナメントが見つからない場合はどうなりますか？これまでのところ、204応答を返しています。まあ、ジャージーはnull、そのメソッドの1つから戻るときに私のためにそれをやっています。これは、上記のルートに対応するメソッドです。 @Path("/{id}") @GET @Produces(MediaType.APPLICATION_JSON) public Tournament getTournament(@PathParam("id") String id) { Optional<Tournament> optTournament = tournamentDao.getTournament(id); if (optTournament.isPresent()) return optTournament.get(); return null; } 私の質問は次のとおりです。リソースが見つからなかったので、204: No Content応答を返すことは問題あり404ませんか、それとも代わりに応答でなければなりませんか？ それを404に変更する必要がある場合、明らかな質問：メソッドのシグネチャを変更する必要がありますか？これで（タイプTournament）のトーナメントが返されない可能性があるため、メソッドは異なるように見えるはずです。Response代わりに、型を戻り値の型として使用する必要がありますか？

15 java  rest  web-services  http 

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

ベンダーのAPIを使用していると仮定して、APIが期待どおりに機能することを確認する方法は？ 私の主な懸念は、ベンダーがコードの変更をプッシュし、APIを破ることです。継続的にテストするための何らかの自動ソフトウェアが必要です。これに対処するには？

14 testing  api  rest  continuous-integration  integration-tests 

Roy Fielding（HTTP仕様の主要著者の1人）によると、RESTについて議論する際に、彼の独創的な論文Architectural Stylesで次のように言及しています。 [E]クライアントからサーバーへの各リクエストには、リクエストを理解するために必要なすべての情報が含まれている必要があり、サーバーに保存されているコンテキストを利用することはできません。 「保存されたコンテキスト」とは、次のページのページ番号が何であるかなどのアプリケーションの状態と、データストア、イメージなどのリソースの状態を指します。 純粋な休憩（上記の論文に準拠する実装として定義されている）のほとんどの試みは、サーバー上のセッションデータの保存に依存しているために失敗しなければならない（永続的またはその他）と言っても過言ではありませんか？ セッションの概念は、特にWeb開発者にとっては一般的ですが、上記の定義に従ってRESTfulですか？

14 rest 

WebサービスAPIの作成を検討しており、RESTサービスの作成を検討しています。このコンテキストでのODataの意味は？ODataとRESTの違いについて説明してください。

14 rest 

単一ページアプリケーションに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 

APIを設計する際に、PUTペイロードに更新対象のリソースのIDを含める必要があるかどうかという疑問に思いつきました。 これは私たちが現在持っているものです： PUT /users/123 Payload: {name: "Adrian"} ルートコードはURIからIDを抽出し、更新を続行します。 APIの最初のユーザーは、ペイロードにIDを許可しない理由を疑問視しています。 PUT /users/123 Payload: {id: 123, name: "Adrian"} 許可しなかった理由は、ペイロードとURIでIDが重複しているためです。 これについてもう少し考えて、リソースをURIに結合しています。 URIにIDがない場合、ペイロードを修正する必要があります。 PUT /no/id/here Payload: {name: "Adrian"} < What user??? しない理由はありますか？

13 rest  resources