Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。あなたのリクエストに応じて、大切な情報を見逃すことなく、ノイズを減らす機能を開発しました。お気に入りのトピックを選択して、メールとウェブで通知をもらいましょう。今から10年ほど前に、RESTとSOAPベースのシステムを中心とした活動の盛り上がりがあった。何人かの著者がそれぞれの長所と短所を書き上げたり、導入を検討すべきなのはどちらなのかを論じたりしていた。多くの注目がSOAPベースのWebサービスからRESTとHTTPに移行するにつれて、意見や議論は下火になり、多くのSOA実践者が分散システムの基盤としてREST(あるいはプレーンなHTTP)を採用するようになっている。insanity)”だと断じた。氏の記事は長く、内容も詳細にわたるが、その要点となっているのは、RPC機構ならば“数時間”でできる単純なAPIの提供が、RESTを使うことによって複雑で時間のかかるものになるという氏の見解である。?理由は次のとおりだ。標準もなければ、詳細な仕様もありません。回避策の山があるのみです。メソッドをCRUD操作にマッピングするのは単純な作業ではない。既存のリソースを再利用せずに新たなリソースインスタンスを生成するのか、それをいつ行うか、どうやって判断すればよいのだろう?HTTPのエラーコードは限定的で、詳細なエラー状況を表すには問題が多い、というのが氏の見解だ。氏のリストはさらに続く。その結果は?何時間もかけて、車輪の再発明を行うことになります。目的にぴったりでもなければスマートでもない、壊れていて、もろく、理解するには山のような資料が必要で、それとは知らずに仕様に反している車輪です。続いて氏は、PUTなど特定のHTTP動詞を詳細に検討している。PATCHやDELETEについてはほとんど取り上げていない。リソースの更新にPUTを使いたいですか?OK。Specifications)によると、データ入力はGET経由で受信した表現と同じでなければなりません。Conflict”を期待しますか(GETを発行しなくてはなりませんが...)?適当な値を設定して、サーバが無視してくれるように(無音エラーという幸運を)祈りますか?どれを選ぶにせよ、RESTが読み取り専用について何も考えていないことは明らかです。これは当分の間、修正されることはないでしょう。その一方でGETは、その前のPOST/PUTで送信されたパスワード(やクレジットカード番号)を返送する危険性をはらんでいます。このような書き込み専用パラメータについても、幸運を祈る他ありません。PUTには競合状態に陥る危険性があることも忘れてはなりません。いくつかのクライアントが違うフィールドを更新したいだけなのに、互いの変更を上書きしてしまったらどうしますか?エラー処理、RESTのアーキテクチャ上の概念、その他多くの側面を詳細にレビューして、問題点が指摘されている。RESTの支持者も、信じていない者にも、一読の価値のある記事だ。氏は、次のように結論付ける。透過的なRPCは99パーセントの人々が本当に求めていたものであり、既存のプロトコルは、例え不完全であったとしても、十分に機能するものでした。Webの最底辺の共通分母であるHTTPへの極端な執着がもたらしたものの大部分は、時間と知力の壮大な無駄遣いです。RESTは簡潔をうたいながら、複雑性をもたらします。RESTは堅牢性をうたいながら、脆弱性をもたらします。RESTは相互運用性を約束しながら、実際には異種性をもたらしているのです。RESTは新たなSOAPなのです。記事への多くのコメントを読むと、一部に賛成する意見があるのは確かだが、大半は氏の意見に同意せず、さまざまな欠点を指摘している。Vasilakis氏は、次のように述べている。Royの論文を読んでみるべきです。あなたがここで攻撃しているのは、RESTに対する一般的な誤解です。Royが論文で述べているように、RESTはすべてのケースには適合しないかも知れませんが、クライアントをコントロールできないような場合には非常に適しています。自己記述的であるがために進化の可能なモデルが他にあるならば、教えて頂きたいものです。RESTはまさにそれなのです。Storeのアプリのように。Appleに拒否されたり、アクセスやアップデートのできないセンサデバイスに妨げられなければ、ですが)。このようなシナリオのためのRESTであって、GraphQLでは制限や問題が多いのです。発展性に関する問題を解決するモデルが他にあるのならば、ぜひ教えてください。RPCはそのひとつではありません。何を読んだのですか?まともなAPIを設計するために時間を費やすことが不満なのですか?それはあなたの責任であって、開発者としての目標ではないのでしょうか。RESTに関連するものや“関連しない”もの、ありとあらゆる問題に不満を連ねるのは、幼稚で無意味な行動です。どんな言語、プロトコル、仕様、コンセプトにも不満は現れます。問題やバグ、構文が非論理的、VMが遅い、型がない、厳格過ぎる、簡略的過ぎる、機能が多過ぎる、十分にOOPでない、など。それらがあればこそのソフトウェアエンジニアリングなのです。Patti氏からは、すばらしい記事です。表現はやや乱暴ですが、多くの裏付け証拠を揃えて、合理的かつ詳細に意見を述べています。SOAPという論理的純粋性の模範を人々が見限る、あるいは見限ったのは、この記事の内容を信じるならば、Javaや.NETのツーリングでの開発作業があまりにも、本当にあまりにもひどいものだったからでしょう。よくなっているとは聞いていますが、人は苦痛を感じると、新しいツールを取り入れることで対処しようとするものです。私たちが不幸な道を選んだのかも知れない、離れるべきだ、と主張していますが、ではどうすればよいのでしょう?新しいプロトコルをいくつか引用していますが、私が知りたいのは、SOAPあるいはRESTを直接的に置き換えることのできる、具体的な例なのです。コメントだけでなく、さまざまなソーシャルメディアプラットフォームでもこの記事が取り上げられた。SOAP”という記事を著すことになった。RESTとHTTPに関してありがちな誤解が、この記事全体にたくさん見られます。した混乱を通じて、人々を教育しようとこれまで務めてきたのですが、いまだ蔓延し続けているようです。私の発言力が十分ではなく、書き物も行動も不十分であることは確かです。これらは私自身の書籍に対する不満であって、著者に向けたものではありません。元記事に匹敵する長さの記事で、氏は、元記事で詳細に議論されたRESTの問題を検討している。記事中の“壊れてもろい車輪”を作る件については、次のように述べている。確かにイライラします。APIは嘲笑されることも少なくありません。APIでは確かにドキュメントは不要であるべきですが、私自身はここ数ヶ月間、開発中のAPIのドキュメント作成に費やしています。APIは文書をほとんど必要とはしません。PUTその他の危険性に関する元記事の議論については、“どうやらPUTの目的を理解していないことから生まれた不満のようだ”。実際に、元記事を読んでいなかったとしても、氏の反論はそれ自体が一読の価値のあるものだ。その議論の根底にあるのは、RESTに関する元記事の不平不満は、すべてではないにせよ、大部分が誤解によるものだ、という指摘である。記事は次のように結論付けている。RESTが複雑な問題であることは確かです。RESTを理解していると自分では思っていて、それを理解していない人に出会った時に誤った評価を下す人が多過ぎるのです。...確かにそうなのかも知れない。両氏の議論はさらに続いているようで、Philは記事の更新を続けている。著者とは建設的な対話を続けていて、RESTの仕組みについて理解してくれているようです。読者の中にも興味のある方がいるかも知れません。関心のある読者はそれをチェックして、対話が進む様子を見るのもよいだろう。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員��して、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。