Perfect-SwiftのRESTサーバー

ほとんどのiOS開発者は遅かれ早かれiOS SDKの世界でcr屈になります。 そして、その理由は、IOSが深刻な開発の機会を十分に持っていないということではありませんが、最新の深刻なアプリケーションにはクライアントサーバーアーキテクチャがありますが、iOS開発者が利用できるのはClient Worldだけです。 サーバー開発は、モバイル開発者がAPIの何かを変更するという要件に非常にjeしているプログラマにとって 、サーバー鹿に翻弄されます。 最も単純なAPIを実装するには、独自のパラダイムとニュアンスを備えた別のプログラミング言語を習得する必要があるという事実に楽観主義を加えることはありません。 パイロットのアイデアを打ち破るには、外部から人々を引き付けるか、エイリアンの夢の世界（PHP、Pyton、Ruby、C＃）に突入する必要があります。 Objectove-C / Swiftキャンプのすべてがそれほど悪いですか？ まったく違います。 サーバー開発のテーマについて少し調べてみると、かなり興味深い取り組みに出くわしました。これは、真のクロスプラットフォームソリューションになると主張しています。つまり、OSXと* nixシステムの両方で同じように機能します（Windows、C ＃誰も動かない-あまりにも多くのグッズ）。

プロジェクトの作成者が主張するとおり、パーフェクト-Swiftプログラミング言語を使用してアプリケーションやその他のRESTサービスを作成する開発者にとって理想的なWebサーバーおよびツールキットです。 「理想」はしゃれにすぎないことは明らかですが、同時に、提案された解決策に精通した後、この声明に少し真実があるという事実に傾き始めます。

「プレス」は、新しいプログラミング言語のアプローチに関する記事を掲載しました。これは、アップルによる簡単な提出により業界標準になる可能性があります。 大衆に昇格したSwiftに基づく言語。 原則として、これに関する記事はより多くの質問を引き起こし、すべてを再トレーニングするのにうんざりしている人たちにとってはさらに迷惑です（Swift自体は非常に急速に変化します）。 しかし、問題の研究を掘り下げて、すべてが見かけよりもはるかに優れていることが明らかになりました。

Perfectは、新しいサーバー開発言語ではありません。 Perfectは、最新の実装（Swift 2.2の執筆時点）のSwiftのみを使用してREST APIサービスを作成できるサーバー環境です。クライアント開発者が毎日しなければならないことを超えるものはありません。


すること：名刺ページ（スタブ）を作成して、サーバーにアクセスするときにそれを実証します。 GET / POSTリクエストに応答するREST APIサービスを簡単に作成する可能性を示します。 静的なサイトページの動的な形成のメカニズムを示します。 さらに、これはすべてSwiftで行います。





ですから、旅の出発点は適切な環境の創造です。 残念ながら、歩き続ける道はそれほど明白ではなく、ワークスペースの作成からXcodeでのスキームの変更まで、非常に奇妙な操作が数多く含まれます。 プロジェクトの作成者が作成したビデオに、ステップバイステップのガイドが示されています。 記事の各ステップを説明することは、ハブにとっての「翻訳」というトピックにすぎません。 パーフェクト機能の実用化に焦点を当てたいと思います。パーフェクト機能は、コマーシャルには存在しないか、 巨大な神秘的な形でそこに表示されます。 ところで、著者によって公開されたビデオの中には、有用というよりも有害なものがあります。



はじめに、概念を理解しましょう。 Perfectは、サーバーライブラリ（PerfectLib）とミニマリストインターフェイスを備えたスタートアップアプリケーション（Perfect Server）の2つの部分で構成されています。 どちらのアプリケーションもオープンソースであり、理論的には、自分でニーズを変更/終了できます。 ただし、これを行うことは強くお勧めしません。 個人的に、私は常に何かを改善するために忍び寄っています。 ただし、PerfectはSwift 3での使用に適応していないことに注意してください。言語の作成者は、Swift 3が「トップツーボトム」サポートを持たないと言います。 Swiftの新しいバージョンにアップグレードするために、すでに行われた変更を完全に取り除く必要があります。

「Hello Perfect！」の段階に到達していない場合は、それを実行する時間です 。必要な環境をここからダウンロードできます。 （プロジェクトサイトのリンクの一部が壊れています）

次に、index.htmlおよびtemplate.htmlファイルを作成し、作業プロジェクトに追加します。 追加した後、ビルドフェーズに進み、「新しいファイルコピーフェーズ」ステップを追加しましょう。



最終的に、ウィンドウは次のようになります。







ほとんどの場合、これらすべてのアクションはプロジェクトページのビデオで説明されています： www.youtube.com/watch?v=J441eJ40PH4ただし、このケースでは、Webページをホストするか、REST APIを使用できます。 私たちは両方のニーズを1つの機会に結合しようとします。

PerfectServerModuleInitコードを次のコードに完全に置き換えます。

PerfectServerModuleInitメソッドの呼び出しはサーバープロジェクト（私の場合はMySwiftServer）にありますが、どのクラスにも関連付けられていません。 別の.swiftファイルに入れました。
PerfectServerModuleInitは、Webサービスへのエントリポイントです。 main関数に似ています。 サーバーライブラリから呼び出されるメソッド。 後でここで何が起こっているのかを説明します。

ここで、さらにいくつかのクラスを追加する必要があります。


HelloHandlerクラスは役に立たないため、主にサーバーが稼働していることを確認するために使用されます。 サーバーの応答は、出力バッファーに行を追加し、クライアント（ブラウザーまたはクライアントアプリケーション）にコールバックを追加することになります。


StaticPageHandlerクラスを使用すると、指定した名前で静的ページをホストできます。 「デフォルトで」index.htmlが使用されますが、原則として、プロジェクトに追加された他のページでもかまいません。


HelpHandlerクラスを使用すると、サーバーによって処理されたコマンドのリストを取得できます。 他のサーバー環境（MS Framework 4.5.1など）では、自己文書化REST APIサーバーを取得できます。 これは、モバイルアプリケーションの開発者にとって非常に便利です。サーバーの開発者にメンテナンスやコマンドの追加を依頼する必要はありません。
更新： 次の記事では、APIドキュメントのメカニズムを改善しました。


CarsJsonクラスは、GET / POST要求が複雑な戻り構造でどのように機能するかを示しています。 返されるデータはAnyObjectによって表されます。


静的なページを返し、対応するフィールドで置換を行うサービスクラス。 デフォルトでは、template.htmlテンプレートが使用されますが、原則として、プロジェクトに追加された他のテンプレートを使用できます。


RESTResponseクラスは、REST APIを使用する重要なクラスであり、最も物議をかもしています。
返されるデータオブジェクトには、次のJSONラッパー構造があります。
{
«data»:{…. },
«errors»:[… ],
"message":"",
"status":200
}


1）一部の開発者は、この形式を明確に受け入れません。 しかし、返されたデータのこの形式に対する説得力のある議論はありませんでした。 ただし、型付き形式には特定の利点があります。 歴史的な伝統によれば、「ステータス」フィールドの値は、操作が正常に完了すると「200」になります。 ただし、HTTP応答とは直接の関係はありません。 これらは常にリクエストヘッダーから差し引くことができ、サーバー環境自体によってクライアント側に送信されます。 「ステータス」フィールドでは、HTTP層ではなく、Webサービスのビジネスロジック内でセマンティックロードを持つ値を渡すことができます。 「メッセージ」フィールドには、サーバー側のアクションを通知するためにユーザーに表示する必要がある文字列が含まれています。 たとえば、特にクライアントアプリケーションの観点からすべてが順調に進んでいる場合のセッションの有効期限に関する情報。 「エラー」：[]フィールドは、異常な状況をクライアントに通知する用語の配列です。 この情報をクライアント側で保存して処理したり、さらに処理するために専用のログサーバーに送信したりすると便利です。 最後に、データフィールド：{.... }には複雑なデータ構造が含まれています-クライアント側で受信されることが正確に予想されるものです。 このアプローチの主な利点は、サーバーの応答が指定されたスキームを満たさない場合、クライアントが明確な良心を持って拒否できることです。 これを整理する方法については、 habrahabr.ru / post / 283012を参照してください。説明したアプローチに反対する開発者は、「配列」プロパティを簡単に変更して、説明したラッパーなしで生データを返すことができます。

2）Perfect開発者がJSONオブジェクトを返すために使用することを提案したアプローチに少々驚いた。 提案されたチュートリアルでは、各JSONオブジェクトは、[JSONKey：JSONValue]（[String：AnyObject]と同等）の形式のキー/値のペアを列挙してツリーを順次構築することにより形成されると想定されていました。 次のコードを使用することになっています。

public var json: String
{
let result = ["data":self.data, "status":self.status, "message":self.message, "errors":self.errors]

let jsonEncoder = JSONEncoder()
do {
let respString = try jsonEncoder.encode(result)
return respString
} catch let error as NSError {
print(error)
}
return ""
}
…..
response.appendBodyString(self.json)
response.requestCompletedCallback()


ただし、このコードは、現在CarsJsonクラスに含まれているデータでも完全に動作しません。 さらに、Perfect creatorsチュートリアルのロジックに従う場合、複雑な構造をエンコードするには、返されるオブジェクトごとに独自のクラスを作成する必要があります。 私のバージョンでは、数行のコードで任意のネストのオブジェクトをシリアル化できることは明らかです。 これは、サービスの開始後に確認することは難しくありません。

発射！

すべてが正しく行われると、ブラウザに次のページが表示されます。


サーバーに挨拶する：ブラウザの行に「/ hello」と入力します


実行されるコマンドに関するサーバー情報を要求します。


すべてのコマンドはカテゴリ（GET、POST）に分かれていることに注意してください。 他の述語を使用する場合、それらもこのリストに表示されます。
ただし、/ listコマンドは両方のリストにもあります。 PerfectServerModuleInitによってGETおよびPOSTコマンドに追加されたのは彼女ですが、（！）異なるハンドラーがあります！
ブラウザのコマンドラインからリストにアクセスすると、インデックスページが表示されます。


しかし、特別なアプリケーション（たとえば、無料のPostman）を使用する場合、Postリクエストの本文には、予想されるJSONが含まれます。


JSONはCarsJsonクラスで生成された構造と完全に一貫していることに注意してください。

しかし、GETから/​​ listコマンドを削除するとどうなりますか
Routing.Routes["GET", ["/index", "/list"]] = { (_:WebResponse) in return StaticPageHandler(staticPage: "index.html") }

取得するもの：


このような簡単な方法で、開始ページまたはスタブページを置き換えることで、RESTコマンドの使用をルールとして簡単にマスクできます。これが、オープンAPIを使用したサービスでない場合、/ helpなどの開発コマンドの最後に削除またはブロックされます。 しかし、この機会を別の方法で活用することもできます。GET要求のコマンドに関する詳細を含む情報を表示し、静的ページハンドラーを機能させます。

/ carおよび/ carsコマンドは同じ構造を返すが、Webページとして返されることが予想されます。


ある程度のスキルがあれば、REST APIを作成することは、必要なナビゲーションを備えたViewControllerを作成することほど難しくありません。

エクストリームスポーツのファンは、これらすべてをLinuxで実行しようとすることができます。

更新：
チュートリアルでJSON応答の神秘的なシリアル化が使用された理由についての説明がありました-すべてのNSメソッド（NSJSONSerializationを含む）はUbuntuで動作を停止します。