サーバーAPIプロジェクト


Swift はサーバー上で驚くほどの可能性を秘めており、サーバー側の開発にさらに優れた言語を提供しています。Swift には、サーバーフレームワーク間で共通の優れた低レベル API が必要です。サーバー API プロジェクトは、ネットワークやセキュリティなどの分野でコアの機能を提供するため、Swift プログラムはこの機能を提供するためにプラットフォーム固有の C ライブラリに頻繁に依存する必要がなくなりました。その結果、開発者は、複数のプラットフォームのプログラミングスキルと知識も必要なく、純粋な Swift コードを使用してフレームワークとサーバーアプリケーションを作成することができます。


開発の非常に早い段階で、サーバー API には以下のような重要な特徴を持つように意図されています。


Server API プロジェクトは、Swift.org オープンソースコミュニティの一環として管理されています。サーバー API は開発の初期段階にあり、当初からこれらの API を公開で設計し、ビルドできることに興奮しています。このプロジェクトは、Swift 言語の特定のバージョンとともにリリースされる予定はまだありません。このプロジェクトは、Swift がバージョン 4 に向かって進んでいくうちに、独自のペースで成熟することができます。


フォーカスエリア


このプロジェクトでは、まず、ベースネットワーキング、セキュリティと暗号化、および HTTP 解析のための API 提案の作成に焦点を当てます。


移植性


Server API の重要な目標は、Swift が現在利用可能なプラットフォームの両方をサポートし、Swift サポートが追加されたときや新しいプラットフォームを採用する立場にあることです。つまり、コードの移植性を保証するために、プラットフォーム間で API が一貫していなければなりません。ただし、プラットフォームごとに代替の実装が存在する可能性があります。さらに、API がすべてのプラットフォームにわたって機能の最低限の共通点だけを提供するのを避けるために、プラットフォーム固有の拡張機能を追加することができます。


外部ライブラリの使用


プラットフォーム上に十分にサポートされている既存のライブラリがある場合、設計された Swift API 仕様を満たしていれば、Swift オーバーレイと共に使用するために評価する必要があります。将来的に純粋な Swift コードを使用して API を実装することが望ましいかもしれませんが、既存のライブラリを使用すると、機能がより迅速に提供され、Swift は既存のコミュニティから利益を得ることができます。


その後、パフォーマンスの向上、ユーザーエクスペリエンス (使用法、インストール性)、保守などの利点がある純粋な Swift の実装を API に進化させることができます。


この目的のためにあるライブラリを使用するには、外部ライブラリへの依存を Swift プロジェクトに追加するという 汎用のポリシー に従って、プロジェクトリーダー が明示的に承認しなければならないことに注意してください。


ワークグループ


これらの API の作成は、ステアリング (舵取り) チーム、サーバーサイドの Swift コミュニティの関係者、および関与したいと思う人で構成されるワークグループによって調整されます。ワークグループは、ステアリングチームメンバー、ステークホルダー (関係者)、および投稿者の 3 つの役割で構成されています。参加者は、ワークグループ内で複数の役割を果たすことができます。


関係者として参加する、設計の議論に参加する、メーリングリストに質問したり、質問に答える、バグを報告したりまたはトリアージする、プロジェクトにリクエストを送信して実装したりテストするなど、さまざまな活動に参加することで、Server API ワークグループに参加できます。


舵取りチーム


ワークグループは、Swift の主要な コアチーム と同じように、全体的な技術指向の提供を担当するステアリングチームを持ち、さまざまな API の取り組み (たとえば、ネットワークセキュリティと HTTPS の HTTP との統合など) と Swift コアライブラリと言語を幅広く提供します。舵取りチームのメンバーシップは投稿ベースであり、時間の経過とともに進化すると予想されます。


最初の舵取りチームは、以下の人々 (およびその GitHub ID) で構成されています。


さらに、特定の API 分野に専念するために、サブチームが時間をかけて形成されることが期待されます。


ステークホルダー


ワークグループには、サーバー側のフレームワークまたはアプリケーションを表すステークホルダーもあります。それらは、反復的な設計と実装プロセスの一環として、使用目的および API 設計に関する早期の入力を提供し、新しい API をそのフレームワークに採用する責任があります。


ステークホルダーとしてワークグループに参加して去ることは、簡単なプロセスです。唯一の要件は、ワークグループ GitHub プロジェクト のステークホルダーリストに自分の名前を追加し削除するリクエストを発行することです。このプロジェクトは、正式なワークグループの議論の招待状にあなたを追加したり削除したりします。


最初のステークホルダーは、以下の人から成り立っています:


開発プロセス


サーバー API ワークグループの指導の下で、新しいサーバーに焦点を絞った API の開発は、API の提案、プロトタイプ化と開発、およびリリースという 3 つの段階で行われます。


API の提案


新しい API の提案は、サーバー API 舵取りチーム、ステークホルダー、および投稿者によって作成されます。最初の API 提案は、詳細なアーキテクチャーと設計を含む完全な API 仕様ではありません。最初の提案は、使用目的に焦点を当て、以下の事を強調する必要があります。


提案された関数が追加するに足りる合理的なものであること、それらがサーバー API ワークグループの権限内に収まること、全体的なアプローチが有効であることを検証する舵取りチームとステークホルダーから、API 提案が審査され、承認されます。


提案は、Swift 発展プロセスの "ピッチ" として、幅広い Swift コミュニティと社会に適合化させられています。


プロトタイプ化と開発


舵取りチームとステークホルダーから API 提案が承認され、Swift の発展を介して広範なコミュニティからの入力が受けられると、プロトタイプ化と開発が始まります。これは 4 つのステップを含む反復プロセスです。


  1. 開発:孵化リリースを作成するワークグループの投稿者によって開発が行われます。関数は段階的に追加され、開発プロセスの一環としてテストとマニュアルが追加されます。

  2. リリース:十分な新しい関数が開発されたら、舵取りチームとステークホルダーが新しい孵化リリースを提供するためにコードを分岐します。テスト、採用、フィードバック用のリリースの利用可能性は、Swift evolution-announce メーリングリストを使用して発表されます。

  3. 採用:孵化リリースは利便性、適用範囲、品質に関する API を評価するためにステークホルダーと、より広いコミュニティによって採用されます。

  4. フィードバック:最後に、ステークホルダーと広範なコミュニティからの全てのフィードバックは、次の開発サイクルにフィードバックされます。

関数のフルセットが開発、リリース、採用、フィードバックされると、舵取りチームとステークホルダーは正式なプレビューリリースを行います。


リリースプロセス


最初のピッチと開発のマイルストーンで広範囲のコミュニティからフィードバックを得ることに加えて、プレビューリリースが利用可能になると、正式な Swift Evolution の提案が公表され、Swift Evolution メーリングリストを通じて発表されます。これにより、最終的な API とアーキテクチャをレビューし、ライブラリが公開される前にフィードバックを提供する正式な機会が与えられます。


メーリングリスト


サーバー API ワークグループは、一般的な議論のために swift-server-dev メーリングリストを利用しています。





目次
Xcode 9 の新機能

SwiftLogo
  • Swift について
  • 特徴
    安全
    Swift.org とオープンソース
    プロジェクト
    プラットフォームサポート
    アップルのプラットフォーム
    Linux
  • ブログ:Swift 4.0 リリース!
  • 言語の更新
    文字列
    コレクション
    アーカイブとシリアル化
    その他の言語の更新
    新しい互換モード
    Package Manager の更新
    文書化
  • プラットフォーム
  • Linux
    Apple(Xcode)
    ソース
  • Swift のローカルリファクタリング
  • リファクタリングの種類
    カーソルベースのリファクタリング
    レンジベースのリファクタリング
    診断
    テスト
    文脈上のリファクタリングテスト
    コード変換テスト
    Xcode との統合
    潜在的なローカルリファクタリングの考え方
  • Swift のダウンロード
  • リリース
    Swift 4.0
    Swift 3.1.1
    Swift 3.1
    Swift 3.0.2
    Swift 3.0.1
    Swift 3.0
    Swift 2.2.1
    Swift 2.2
    スナップショット
    基幹となる開発(マスター)
    古いスナップショット
    Swift 4.0 の開発
    古いスナップショット
    Swift 3.1 の開発
    古いスナップショット
    古いリリースの分岐
    ダウンロードを使用して
    インストール
    MacOS でのコード署名
    Linux
    必要
    サポートしているターゲットプラットフォーム
    インストール
    アクティブな署名鍵
  • Swift 4.0 入門
  • Swift のインストール
    Linux の場合
    REPL の使用
    パッケージマネージャの使用
    パッケージの作成
    実行可能ファイルの作成
    複数のソースファイルの操作
    LLDB デバッガの使用
  • 文書化
  • Swift プログラミング言語
    翻訳
    API 設計ガイドライン
  • API 設計ガイドライン
  • 目次
    基礎
    ネーミング
    明確な使用の促進
    流暢な使用を目指す
    用語をよく使う
    規約
    一般的規約
    パラメータ
    引数ラベル
    特別な命令
  • Swift 4 への移行
  • 移行前の準備
    Swift 移行アシスタント
    Swift 4 移行の変更の概要
    SDK の変更点
    注目すべき特別なケース
    新しい String
    デフォルトのパラメータ値は public です
    移行の後
    移行に関する既知の問題
    Carthage/CocoaPods プロジェクトの使用
    その他
  • Swift 3 への移行
  • 移行前の準備
    Swift 移行アシスタント
    Swift 3 移行変更の概要
    API 設計ガイドライン
    SDK
    Swift 標準ライブラリ
    言語
    移行後
    Carthage/CocoaPods プロジェクトの使用 既知の移行の問題
    Swift 標準ライブラリ
    SDK
    Swift 3 言語
    その他
  • ソースコード
  • コンパイラと標準ライブラリ
    Core Library
    パッケージマネージャ
    Xcode の Playground サポート
    クローンされたリポジトリ
  • コミュニティガイドライン
  • コミュニケーション
    コミュニティの構造
    プロジェクトリーダー
    コアチーム
    コードオーナー
    ライセンス
    Runtime Library Exception (実行時ライブラリ例外)
    ソースコードの著作権とライセンス
    投稿
    入門
    コードの貢献 (投稿)
    新しい機能の提案
    行動規範
    投稿者行動規範 v1.3
    報告
    メーリングリスト
    General Interest
    Swift 開発
    Swift の発展
    通知
  • 投稿
  • 質問に答える
    バグを報告する
    バグのトリアージ
    コードの投稿
    段階的な開発
    メッセージをコミットする
    変更の帰属
    コードテンプレート
    コードのレビュー
    テスト
    品質
    コミットアクセス
    外部ライブラリ依存関係の追加
    Swift 発展プロセスへの参加
    LLVM と Swift
    LLVM の変更はどこで行われますか?
    Swift と LLVM 開発者ポリシー
  • Swift の継続的インテグレーション
  • 構成
    ジョブの組織
    ジョブの構成
    使用法
    リクエストのテスト
  • Swift ソースの互換性
  • プロジェクトの現在のリスト
    プロジェクトの追加
    合格基準
    プロジェクトの追加
    プロジェクトの維持
    リクエストのテスト
    プロジェクトをビルドする
    フォーカスエリア
  • ABI の安定性
  • データレイアウト
    メタデータ型
    切り分け
    呼び出し規約
    実行時
    標準ライブラリ
  • サーバーAPIプロジェクト
  • フォーカスエリア
    移植性
    外部ライブラリの使用
    ワークグループ
    舵取りチーム
    ステークホルダー
    開発プロセス
    API の提案
    プロトタイプ化と開発
    リリースプロセス
    メーリングリスト
  • コンパイラと標準ライブラリ
  • コンパイラのアーキテクチャ
    標準ライブラリの設計
  • パッケージマネージャ
  • 概念の概要
    モジュール
    パッケージ
    製品
    依存関係
    例の使用法
    ライブラリパッケージの作成
    ビルド構成文の使用
    依存関係のインポート
    副依存関係の解決
    コミュニティの提案
  • Swift コアライブラリ
  • プロジェクトの状態
    Foundation
    libdispatch
    XCTest
  • REPL とデバッガ、プレイグラウンド
  • なぜ REPL とデバッガを組み合わせるのか?
    Xcode プレイグラウンドサポート












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)












    トップへ(Swift 4.0)