Clever Geek Handbook

REST / CRUD。 私はそれを間違って調理していますか？

エントリー



RESTは、サーバー上のオブジェクトを操作するための非常に興味深い方法です。 RESTツールを使用してCRUDインターフェースを実装することは、迅速かつ簡単です！ 今日、私の意見では、REST / CRUDのどのアプローチが間違っており、プロジェクトに有害であるかを示します。



すべてのリソースに必要



ストーリーを続けるには、オブジェクトプロパティの最小セット、アドレス指定、その他の楽しみをすぐに決定する必要があります。 始めましょう：

slugとidの重要な違い




sql-tankers（違反なし）について説明します。



たとえば、users.idはidですが、users.loginはかなりスラッグです。



そして今、「すべてのオブジェクトは指定されたプロパティを持たなければならない」という公理のためにそれを取り、オブジェクトに広がらないように、それらを__link__プロパティに押し込みます。例えば： 

{ __link__: { url: 'http://localhost/api/users/vasya', urn: '/api/users/vasya', resource: 'users', slug: 'vasya' } }


ところで、これは有効なオブジェクトです。 一部のURL（「 localhost / api / users 」ではない）から戻る可能性があります 。 このようなオブジェクトを受け取った開発者は、__ link__からurl / urnのデータを要求する必要がありますが、それについては後で詳しく説明します。

ところで、「右側」-追加しないでください。 プロパティ "__lnk__"、ただしこれらの目的にはX-URI、X-URN、X-URLなどの形式のヘッダーを使用しますが、すべてのWebユーザーがヘッダーで作業することを好むわけではありません。 モールは死体を持って走った。

うーん...同様のプロパティを持つREST API実装はいくつありますか？ 自転車を発明したのでしょうか？



CRUD /読み取りまたはHTTP / GET



ここではすべてが簡単です。 URLを取得し、オブジェクトを要求します。しかし、「and」はどうでしょうか。 そして時々この答えを観察します：

例： 
  HTTP / GET http：// localhost / api / users 


 { status: true, count: 100, data: [ { login: 'vasya', name: 'Vasilii', id: 146, __link__: { url: 'http://localhost/api/users/vasya', urn: '/api/users/vasya', resource: 'users', slug: 'vasya' } }, { login: 'petya', name: 'Petr', id: 145, __link__: { url: 'http://localhost/api/users/petya', urn: '/api/users/petya', resource: 'users', slug: 'petya' } } ] }


ここで何が問題なのか：

結論：これがどれほど正しいかはわかりませんが、これまでのところ、すべての議論がこのアプローチを支持しているわけではありません。



答えは次のようになります。 

 [ { __link__: { url: 'http://localhost/api/users/vasya', urn: '/api/users/vasya', resource: 'users', slug: 'vasya' } }, { __link__: { url: 'http://localhost/api/users/petya', urn: '/api/users/petya', resource: 'users', slug: 'petya' } } ]


同時に、カウントはHTTP / HEADに存在する必要があります。 リソースに直接関係するものではありませんが、コレクションの状態を特徴づけます。 繰り返しますが、ユーザー数を表示する必要があります。 になる方法 すべてを選択してJavaScriptでカウントしますか？ 要素の数を取得する新しいURLを作成しますか？ なんで？ HTTP / HEAD収集リクエストを作成します。 データはなく、見出しのみが返されます。



懐疑論者は言う：すべての要素を描くには、バックエンドに多くの要求をしなければならない、

私は答えます：HTTP / 1.1 / Keep-aliveは私たち全員を救います。 JavaScriptフレームワークとキャッシングを使用する場合、ほとんどのデータは初期化中に一度だけ要求され、その後はHTTP / 304応答でのみ要求を交換します（リソースは変更されません）。



ウェブマスターがこのアプローチを好まない理由を知っていますか？ 通常の表示では、サーバーからのデータの受信を制御する必要があります。

例：データがプロパティとともにすぐに到着した場合、同期を気にせずにループ内に複数のdivをすぐに描画できます。 ユーザーと4行を表示するために4つのリクエストを行う場合、何らかの方法ですべてのリクエストのステータスを監視する必要があります。 つまり すべてのリクエストが解決するまで-何も描画しないでください。 そのような問題の解決策については、「約束と​​未来」を参照してください。 それらはすべて強制同期のためのコードを持っていますが、私はそのまますぐに描画します...



PS午前2時30分 リソースのネスト、大規模なDELET / POST / PUTについて話したかったのですが、おそらく眠りにつくでしょう。 この作品は一般に公開します。 コメントで話してください-続ける価値はありますか、それとも一般的な真実が流行していませんか？

PPSサードパーティのデベロッパーからREST APIを使用する際に強化する必要のあるさまざまなレーキに感謝します。

みんなありがとう！


More articles:


All Articles