問題タブ [restful-architecture]

Jsonを出力してDjangoでRESTApiを作成しようとしています。ターミナルでcurlを使用してPOSTリクエストを行うと、問題が発生します。私が得るエラーは

このURLをPOST経由で呼び出しましたが、URLがスラッシュで終わっておらず、APPEND_SLASHが設定されています。Djangoは、POSTデータを維持している間はスラッシュURLにリダイレクトできません。フォームを127.0.0.1:8000/add/（末尾のスラッシュに注意）を指すように変更するか、Django設定でAPPEND_SLASH=Falseを設定します。

私のurl.pyは

そして私の見解は

私はそれがJsonを与えていないことを知っていますが、ターミナルでPOSTリクエストを行うときに上記の問題が発生しています

でも、私はdjangoを初めて使用します。

Java を使用して REST API を作成しようとしています。

現在、フロント エンドには socialauth を使用しているため、facebook/twitter/yahoo/hotmail/gmail ユーザーがアプリケーションにサインインできます。

ユーザーがサインインすると、自分のアカウントのデータにアクセスできるようになります。各ユーザーが自分のデータにアクセスできるようにする REST API を作成したいと考えています。Jersey フレームワークを使用して REST API を作成する基本は理解しましたが、アプリケーションに正しくログインしたユーザーのみが REST API を介してデータにアクセスできるようにするにはどうすればよいですか?

私が考えたのは、ユーザーがログインしたときに、ユーザーの電子メール ID をセッションに保存することです。そして、ユーザーが API にリクエストを行うたびに、セッション内の電子メール ID が入力パラメーターとして REST API に渡され、REST API は、データが電子メール ID パラメーターと同じ電子メール ID を要求されていることを確認します。

上記の考え方は正しいでしょうか？上記のシナリオで REST API を実装するための推奨/最適な方法は何ですか?

mySQL のデータベース構造が完璧とは言えず、アプリケーションの一部でパフォーマンスが低下している PHP アプリケーションを維持するのは困難です。

最初のステップで、すべてのデータベース呼び出し (SELECT、INSERT、UPDATE) に対してアプリケーション サーバー上に REST Web サービスを構築することを検討します。アプリケーションに悪影響を与えることなく、テーブル構造とデータベース呼び出しを最適化します。

そして最後のステップで、PHP アプリケーション自体をリファクタリングします。

php アプリケーションは、約 5 から 10 の同時ユーザー用の情報システムで、ラウンド 15 のテーブルがあります。

これは良いアプローチですか？REST ソリューションの落とし穴はどこにありますか?

前もって感謝します！

ポンゴ

phprestsql を使用してデータベース用の REST インターフェイスをセットアップしようとしましたが、ログインしてデータベース テーブルを表示することはできますが、その内容を表示しようとすると、次の結果が得られます。

オブジェクトが見つかりません!

要求された URL はこのサーバーで見つかりませんでした。URL を手動で入力した場合は、スペルを確認してからもう一度お試しください。

これがサーバー エラーであると思われる場合は、ウェブマスターに連絡してください。エラー404

私のphprestsql.iniの内容は次のとおりです。

.htaccess.example には次のものが含まれています。

私はこの種のものにまったく慣れていないので、提案されたアイデアは大歓迎です:)

ps 3306 ポートをテーブル コンテンツ リンク (例: http://172.16.2.2:3306/rest/device ) に挿入すると、次のメッセージが表示されます。

文字はhtmlドキュメントのソースにも表示されるため、エンコードエラーではないと思います...

RESTful に関するほとんどのチュートリアル、ドキュメント、記事などで、いくつかの同じ点に出くわしますが、これらの「RESTful にする理由」の点が実装されていることはめったにありません。

たとえば、私はこれを何度も読みました：

• コンテンツ タイプ

  HTTP ヘッダーの使用

  URL の拡張子

これが実装されているのを見た API に出くわしたことはありません。私がこれまでに使用したすべての API では、常に URL の末尾に XML または JSON を追加する必要がありました。彼らはそれを間違っていますか？

• バージョニング

  バージョン メディア タイプ

  アプリケーション/vnd.something.v1+json

  カスタム ヘッダー

  X-API バージョン: 1

  URL のバージョン

  /v1/resouce RESTful ではありません。URL にバージョンを入れることで、別のリソースを作成します

下位互換性のない機能を導入する必要がある場合は、別のリソースを作成するのが正しいことですか?

ここでも、私が使用したすべてのバージョンの API で、URL に v1、v2 を使用しています (google、imgur など)。

これらのポイントを実装しないと、API は RESTful と見なされなくなりますか?

これらの点を明確にしていただければ幸いです。

XMLを生成および消費するいくつかのWebサービスを作成しています。計画は、JAXBを備えたTomcat6.xでJersey1.xを使用することです。

私が知る必要があるのは; これらのサービスを作成するときに従うべき経験則はありますか？PUTまたはGETを実行するときの一般的な方法は何ですか？消費者は、応答、ステータス、またはオブジェクトが返されることを期待していますか？

私はこれらすべてのシナリオの例を読んで見てきましたが、各著者/ブロガーと、これらの同じシナリオに異なる方法で対処する方法を説明しました。

これをしばらくやっている人からの提案はありますか？

ありがとう

jQuery と Sugar REST API を使用して SugarCRM にログインしようとしています。私は今のところ運がありません。以下はコード スニペットです。

RESTFul は、主に次の 4 つのアクションに基づいています。 GET,POST,PUT,DELETE

itemしかし、aをlocation Atoに変更したい場合はどうすればlocation Bよいでしょうか??

そのためには2つの機能が必要ですか？

DELETE /item/locationA/1

PUT /item/locationB/1

ありがとう。

私のアプリケーションは、親とその子供によって使用されます。

保護者が自分のアカウント ページから子供に関する詳細を編集できるようにしたいと考えています。上のセクションに親に関するフィールドが含まれ、下のセクションに子に関するフィールドが含まれる単一のフォームを想定しています。親に複数の子がいる場合、下のセクションはタブ付きになります。お子様 1 人につき 1 つのタブ。

できればRESTfulな設計を実現したい。これまでに検討したオプションは次のとおりです。

オプション 1 - 親のリソース ルートを介して親とすべての子 (ネストされた子フォームのリスト) を公開し、JavaScript を使用して UI をタブベースのレイアウトに変更します。

オプション 2 - 親のリソース ルートを介して、親と 1 つの子 (ネストされたフォーム) を公開します。同じページを公開しますが、ネストされたルートを介して特定の子を対象とします。

そう：

'GET /parent/1' は、'first' (デフォルト) の子用のネストされたサブフォームを持つ親のアカウント ページをレンダリングします。また、ネストされたルートにリンクする 2 つ以上のクリック可能なリンク (タブとしてスタイル設定) も含まれます。子ごとに 1 つ (例: 'GET /account/1/child/1' および 'GET /account/1/child/2')。

ネストされた各ルートは、「子供」コントローラーによって処理されます。このコントローラーは、実際には、親ルート/コントローラーによってレンダリングされるのとまったく同じ親のアカウント ページをレンダリングしますが、ルートによってアドレス指定された子リソースのサブフォームが適切に入力されます。

オプション 2 は実行可能なアプローチのようですが、フィードバックやその他のアイデアを歓迎します。

新しい REST 専用の Web サービス (モバイル クライアント) を起動して定型コードをすべて排除するための堅牢な REST フレームワークを探しています。たとえば、単純にドメイン モデルを構築してそれを実行できるように、既にこの機能が組み込まれているフレームワークはありますか? を見たいのですが：

• 認証とユーザー モデル
• ロギング
• 基本CRUD
• パーミッション (モデル アクセス用)
• スケーラビリティ

すべての Web サービスは、少なくとも上記の機能を必要とするようです。誰か、どこかで、上記の機能を備えた優れた再利用可能なフレームワークを作成したに違いありません。何か案は？Node.js、Java、またはこれらの機能を提供する PaaS サービス プロバイダーでホスティングすることをお勧めします。