コーヒーブレイク #31。すべての開発者が避けるべきキャリア上の 9 つの間違い。REST API アーキテクチャが人気を集めているのはなぜですか?

すべてのソフトウェア開発者が避けるべきキャリア上の 9 つの間違い

出典: Infoworld 正直に言いましょう。あなたや両親が、もっと簡単にたくさんお金を稼げると考えて、プログラミングを学び始めた人もいます。学校ではコンピューターにあまり興味がなかったし、ソフトウェア開発もあまり好きではありませんでした。これが本当であれば、あなたはいつまでも平凡なプログラマーであることを意味します。はい、私たちの業界では有利なため、あなたは十分な収入を得られるでしょうが、この記事はあなたのためのものではありません。しかし、もしあなたが子供の頃に、電子機器がどのように機能するかを理解するために電子機器を分解して罰せられたとしたら...ビデオゲームの作成方法を学ぶためにインターネットで半夜を費やしたとしたら...貴重な自由時間を次の学習に費やしたとしたら...誰もあなたに尋ねていません...この記事はあなたのためのものです。自分のキャリアに対する認識を変える必要があります。もうコードを書くのは楽しみのためではなく、お金のためにやっているのです。楽しみとして、個人のプロジェクトをサポートすることもできます。ただし、少なくとも日々の仕事を楽しむようにしてください。そうでない場合は、可能であればより良い場所を見つけてください。あなたの目標は、退職基金を開設し、税引後のお金をすべてそれに注ぎ込み、家や車を購入し、やりたいことをすることです。たぶん旅行。同時に、現在の仕事だけでなく、自分のキャリアについても考える必要があります。そのためには、これから説明する 9 つの落とし穴を避ける必要があります。

落とし穴 #1: 1 つのテクノロジーに長期間留まらないようにする

わかりました。C#、Java、JavaScript、Python、Cobol のどれが好きですか。しかし、ほとんどのテクノロジーには、導入、ピーク、アウトソーシング、ニッチ、陳腐化というライフサイクルがあります。つまり、1980 年代に COBOL を知っていたら、それはクールだったでしょう。しかし、Cobol プログラマーは最近ではあまり稼いでいません。つまり、重要なのは、プログラミング言語を 1 つしか知らないと、収入が減るため、遅かれ早かれ出費を削減し、より安い都市に引っ越さなければならないということです。

落とし穴その 2: IT 独占者になってはいけない

投資をヘッジする必要があります。現在市場を支配しているテクノロジーの専門家になるだけでよいように思えるかもしれません。しかし、その後は多くの競争に直面することになります。さらに、専門分野の需要が減少した場合には、すでに撤退計画を立てておく必要があります。たとえば、Java が登場したとき、私は C++ オタクでした。Javaを学びました。数年前、誰もが Ruby がプログラミング言語の新たな新星として話題になり始めました。そしてある時点で、Perl は Java と同じレベルに到達すると思われました。将来を予測するのは難しいため、雇用市場での関連性を確保するにはリスクを回避することが最も安全な方法です。

落とし穴 #3: 流行にしがみつかない

遅かれ早かれ魔法は消えてしまいます。Groovy や Ruby の開発者は雇われません。上司がプロジェクトでレガシー言語の使用を許可する場合、それは上司が気にしていないか、単に無知であるかのどちらかです。ぜひ最新のテクノロジーを学び、活用してください。それらについて最初に知り、その専門家になる準備をしてください。一方で、自分の専門分野への需要が減少した場合には、抜本的な変更を加える準備もしておいてください。言語であれデータベースであれ、夢中になれる新しいテクノロジーは常に他にもあります。

落とし穴 #4: ルールに対するアレルギー

規模の大小にかかわらず、すべての組織には独自の社内ルールがあります。あなたはそれらを研究し、従う必要があります。そうしないと、他の人のゲームの駒になってしまったり、チーム内で孤立してしまうことになります。キャリアと職場での生産的な人間関係に興味がある場合は、オフィスルールで 防御戦術に従うことを学びましょう。

落とし穴 #5: ビジネスへの無関心

「私は単なる開発者であり、ビジネスには興味がありません。」これはどこへも続く道ではない。数えることを学ぶ必要があります。あなたの会社の業績は順調ですか？その主なビジネス目標は何ですか? 彼女の最も重要なプロジェクトは何ですか? テクノロジーやソフトウェアはそれらを達成するのにどのように役立ちますか? あなたの会社は業界全体にどのように適合しますか? これらの質問に対する答えを知らなければ、重要ではない会社の重要ではない人々のための、重要ではないプロジェクトに比較的微々たる金額で取り組むことになるでしょう。

落とし穴その6：「労働組合の団結」の考え方

私が若かった頃、同僚の一人は、ほとんどすべてのことを半年前に計画する男でした。彼は休暇を取るという間違いを犯したので、私はプロジェクト全体を 2 週間で完了させましたが、彼に 1 つの作業を残しました。私は彼がそれを喜んでくれるだろうと期待していました。彼は幸せではないことが判明した。すべては彼があらゆる機会を利用して私を解雇することで終わりました。これが彼の主な目標になりました。彼は新しいディレクターに私のことについて苦情を言ったこともありました。もちろん仕事は全部やりました。私は革新者でした。私は常に物事をより良く、より速く行い、問題を解決するための新しい方法を見つけていました。私が別の仕事に就いた直後、彼は退職しました。何度かカフェで彼に会いましたが、私たちはお互いを知らないふりをしていました。私がこの種の作業に遭遇したのはこれが最後ではありません: 「ゆっくりと物事を進めないと、状況が悪化します。」 私のアドバイス: 正しいコードを書きますが、予期せぬ事態に備えてください。問題が解決できない場合は、ドアをバタンと閉めて放置してください。市場にいるのはあなたの会社だけではありません。

落とし穴その7：自分の価値が分かっていない

「私はお金のためにここにいるわけではありません。」それなら、趣味を持ちましょう。次の給料のことを考えて毎日仕事に行く必要はありません。また、収入が他の人より 50% 少ない場合も、仕事に行くべきではありません。自分の価値を知り、過小評価しないでください。

落とし穴 #8: 仕事を仕事のように扱う

「それはただの仕事です。」いいえ、これはあなたのキャリアのステップです。あなたは永遠にこの仕事に携わることはできません。それで、ここでは何を学べるのでしょうか？次のステップは何ですか? 最終的にどこに行き着きたいですか？この取り組みは、その目標を達成するのにどのように役立ちますか? 周囲に対する意識を高めます。これは長期的には役に立ちます。それは単なる仕事ではなく、旅でもあります。

落とし穴その9: お金だけが問題だと思っている

営業担当者は「コインを投げてくれれば仕事をします」と言うことを好みます。はい、しかし、営業職でない限り、お金のためだけにその仕事に就いている人と働きたいと思う人はいません。自分の仕事に責任のある人とだけ働きたいと思っています。あなたも？一方で、耐えられないほど責任を負う必要はありません。本当に心配しているのが、タブかギャップかという永遠の議論だけである場合は、鎮静剤を服用する必要があるかもしれません。

REST API アーキテクチャが人気を集めているのはなぜですか?

出典: DZone インスタントコミュニケーションは素晴らしいことです。私たちは皆、世界中のどこにいても即座に通信できるという事実に慣れています。デスクトップ コンピューターやモバイル デバイスから、どこにいても、あらゆるものを購入、投稿、添付、選択できます。私たちはこれまでにないほどお互いに、そして世界とつながっています。しかし、どうしてこんなことが起こるのでしょうか？データは「そこから」どのようにして私たちに届くのでしょうか? デバイスとアプリケーションは、アプリケーション プログラミング インターフェイス (API) を使用して相互に通信します。これはまさに「ボンネットの下」にあるエンジンです。これは常に舞台裏にあるものであり、私たちはそれを普通のものだと考える傾向がありますが、私たちが期待するすべての対話性を生み出すのは API です。

APIとは何ですか?

簡単に言うと、API はリクエストを受け取り、何をしたいのかをシステムに伝え、レスポンスを返すメッセンジャーです。視覚的な例として、API をレストランのウェイターとして想像してください。あなたがテーブルに座ってメニューを手に持っていると想像してみてください。キッチンは注文を準備するシステムの一部です。API は、注文をキッチンに送信し、食べ物をテーブルに届けるリンクです。

実際の例を見てみましょう。

私たちは皆、オンラインでフライトを検索するプロセスに慣れており、フライトを予約するには航空会社の Web サイトを操作する必要があることを知っています。データベースにアクセスして、特定の日付に空席があるかどうか、またフライト要件に基づいて予想される費用を確認します。しかし、情報に直接アクセスできる航空会社の Web サイトを使用しない場合はどうなるでしょうか? さまざまな航空会社から情報を収集するオンライン予約サービスを使用するとどうなるでしょうか? このサービスは航空会社の API と対話します。API は、親切なウェイターと同様に、座席の予約や乗客の食事や荷物の好みの選択に関する情報をオンライン サービスに要求するインターフェイスです。API は航空会社からの応答を受け取り、それをオンライン サービスに返し、乗客に情報を表示します。他のすべてのアプリケーション、データ、デバイスの間でも、ほぼ同じプロセスが発生します。これらはすべてコンピューターが制御できる API を備えており、これにより最終的にコミュニケーションが生まれます。

どのような種類の API がありますか?

API アーキテクチャは、主に 2 つの方法で実装できます。情報転送を実装するこれらの方法の 1 つは SOAP で、もう 1 つの主な方法は REST です。API が 2 つのアプリケーション間の通信を提供することはすでに確立しています。次に、SOAP と REST が通信アーキテクチャにどのように正確に適合するかを学びます。

ソープAPI

SOAP (Simple Object Access Protocol) は、W3C と呼ばれる中心団体とコア仕様セットの間で確立された特定の通信原則を備えた仕様に従う Web サービスです。このセットには以下が含まれます:

• 石鹸
• WSDL
• UDDI

SOAP は、2 つのアプリケーションが相互に通信する方法を定義するプロトコルです。2 つのアプリケーションは相互に通信するときに共通フォーマットに従う必要があり、この共通フォーマットは XML 言語に基づいている必要があります。SOAP API の XML は、エンベロープ、ヘッダー、本文で構成される SOAP メッセージ標準に準拠する必要があります。

REST API

これは非常に重要ですが、よく誤解されている Web サービスの概念なので、REST または RESTful API が何を意味するのかを解読してみましょう。REST は、独自のアーキテクチャ原則を使用して 2 つのアプリケーション間の通信を開始する Web サービスです。REST アーキテクチャは、いかなるプロトコルにも従わないアーキテクチャ スタイルであり、厳密な仕様はなく、仕様を管理する中央権威もありません。これにより、REST はあらゆる種類のサービスの使用または作成に多用途に使用できるようになります。Web サービスを作成するときにこれらの原則を適用すると、RESTful Web サービスが得られます。ここで、もう少し詳しく見て、REST アーキテクチャの基礎となる原則を見てみましょう。

統一インターフェース

RESTful アーキテクチャでは、すべてのものをリソースとみなすことができます。たとえば、従業員管理システム用のアプリケーションを作成しようとしているとします。このアプリケーションは、任意の言語、任意のプラットフォーム、および任意のプラットフォームを使用して開発できます。同様に、任意のデータベースを内部サービスの処理に使用できます。REST API におけるリソースの概念は、ユーザーが任意の情報または任意のモジュールをリソースとして定義できることを意味します。従業員管理システムがあれば、作成者は従業員リソース、部門、およびアプリケーションで使用されるその他のモジュールを定義できます。

ステートレス

RESTful アーキテクチャでは、すべての応答とリクエスト、およびサーバー間のすべての通信はステートレスです。これは、サーバーがシステムの現在の状態を維持せず、クライアントがそれ自体で完了するリクエストを送信する可能性があることを意味します。そして、このリクエストは以前のリクエストのいずれにも依存しません。たとえば、オンライン ショッピングでカートに商品を追加している場合、サーバーはカートの状態を維持しないため、ユーザーがサーバーにリクエストを送信するたびに、リクエストが送信された時点のカートの状態が含まれることになります。リクエストが行われました。ステートレスの場合、サーバーがセッションを保存または維持するためのオーバーヘッドがないため、Web サービスのパフォーマンスが向上します。

キャッシュ機能

最後のプロトコルでは、RESTful アーキテクチャではサーバーがセッション状態を保存せず、すべてのキャッシュがクライアント側で行われることに気づきました。クライアントがサーバーにリクエストを送信するたびに、サーバーは実際のデータと、レスポンスをローカルに保存する必要があるかどうかをクライアントに伝える他のメタデータを含むレスポンスを返します。

マルチレベルシステム

REST 原則では、クライアントとサーバー間で通信が行われる場合は常に、クライアントとサーバーの間に複数のレイヤーが存在することができ、これらのレイヤーを使用して、メッセージ変換、パフォーマンス向上、キャッシュ、その他さまざまな目的などの複数の目的を実装できると規定されています。コミュニケーションの各レベルには特定のタスクがあります。複数の通信層によりシステムは効率的に動作し、速度と耐久性が向上します。

リクエストに応じてコードを作成

これは、ユーザーが応答を受信するためにリクエストを送信するときに機能する、RESTful Web サービスのオプションの制限です。応答ではクライアント側のコードを実行できます。この原理により、通信の機能が拡張されます。

REST API がますます頻繁に使用されるようになったのはなぜですか?

REST はほとんどの場合、使いやすく、柔軟性が高く、SOAP に比べて多くの利点があります。たとえば、Web サービスと対話するために高価なツールは必要ありません。REST アーキテクチャはよりシンプルで、簡単にカスタマイズでき、通信モデルを作成するときに特別なスキルを必要としません。サーバーのクライアント側を使用してクライアント関連の情報を保存できるため、効率的に使用できます。REST は、より小さなメッセージ形式を使用し、時間のかかる処理を必要としないため、より高速な対話を提供します。REST は、設計哲学に関しても他の Web テクノロジーに近いものです。

石鹸か休息か？

典型的な Web アプリケーションの要件にとって、SOAP は過剰であることがよくあります。REST は、Web アプリケーションで API が必要な場合に必要なものがすべて揃った、よりシンプルなソリューションです。ただし、タスクを実行するには API をもう少し複雑にする必要がある場合があります。たとえば、自動リクエストに API が必要な場合、そのシナリオには SOAP API が適しています。簡単に言えば、問題が大きく複雑な場合は SOAP を選択し、単純な解決策が必要な場合は REST を選択します。