スプレー、Akka-httpおよびPlay、これは新しいHTTP / RESTプロジェクトの最善策です
ScalaとAkkaアクターを使用して、新しいHTTP/RESTサービスを開発します。
Playの使用経験はありますが、完全なWebフレームワークは必要ありません。私が読んだことから、スプレーは適切な選択だと思います。私の質問は、新しいAKKA-HTTPが到着した後のスプレーの未来から来ています。
SprayプロジェクトはAkka-HTTPプロジェクトから独立して成長しますか、または2つのプロジェクトは1つのAkka-HTTTPにマージされますか？
スプレーで開発を開始した場合、これはどのような影響がありますか？また、PlayはAKKA-HTTPを統合することを読みました。だから私は最終的にはPlayで行くべきではないのだろうか？
ご協力いただきありがとうございます。
スプレーは生産準備が整っていますが、開発チーム（Mathias Doenitz）は現在Akka-httpでTypesafeに取り組んでいます。
Akka-httpのステータスは "development preview" です。 「数ヶ月以内に」完全なリリースの漠然とした約束がありますが、銀行に持ち込むことはできません。
2015年7月29日編集：
Akka-HTTPのステータスは、バージョン1.0 RC4で「リリース候補」になりました。その機能は多くの場合、spray.ioと競合しています。一般的な期待は、spray.ioが開発の勢いを失うことです。現時点では、新しいプロジェクトにspray.ioを推奨しません。
TypesafeのJonas Bonerは、Akka-httpを「Spray 2.0」と呼んでいます。そのため、Sprayの将来のバージョンを期待しないでください。ある時点で切り替えを行う必要があります。 JonasのAkka-httpプレゼンテーションはScala Daysで見ましたが、DSLがほとんど変更されていないため、SprayコードをAkka-httpに移植するのは簡単です。異なります）。
具体的にあなたの質問に答えるには：スプレーは別のプロジェクトとして終了し、Akka-httpという名前でAkkaにインポートされます（Akkaには事前に同等のものがなかったため、マージではありません）。今すぐ開発を開始する必要がある場合はスプレーを使用し、プレビューリリースで避けられないバグに対処する余裕がある場合は、Akka-httpを使用します。スプレーコードは動作を停止することはありませんが、マイナーなバグ修正以外ではサポートされません。すべての新しい機能はAkka-httpに追加されるため、Spray 2.0に更新する代わりにAkka-httpに更新します。
まあ、すべてをゼロから学ぶ必要がある場合は、スプレーを選択することをお勧めします-Akka hhtpのドキュメントは本当に不完全であり、多くのルートディレクティブはまだakka.httpに実装されていません。私はakkaから始めましたが、スプレーに行くことを余儀なくされました...
Typesafe gets Spray（ed）| @typesafe
Akka/Spray統合（Akka HTTPという名前）は、埋め込み可能なRESTサービスを生成および消費する理想的な方法を提供します。
ヨハネス・ルドルフによる
（すでに存在しているかもしれない）akkaサービスにHTTPインターフェースを提供したい場合、それがakka-httpの目的です
ソース： https://gitter.im/akka/akka?at=5874fc9761fac5a03dbe1a6f