Spray Introduction

What is spray ?

Spray是一套轻量级的==Scala Libraries==，基于Akka提供客户和服务器端的REST/HTTP。

我们相信，选择Scala(可能还有Akka)作为创建软件的主要工具后，不仅仅在你的应用层，并且遍及你的整个网络栈(JVM-level)，你都会想要依赖他们的力量。Spray提供：为你的REST/HTTP提供需要的一套集成组件-让你在你选择的栈级别上使用惯用的Scala(and Akka) APIs，所有实现不需要任何Java library上的包装层。

---

Principles

• * Fully asynchronous, non-blocking *
  All APIs are fully asynchronous, blocking code is avoided wherever at all possible.

• * Actor- and Future-based *
  spray fully embraces the programming model of the platform it is built upon. Akka Actors and Futures are key constructs of its APIs.

• * High-performance *
  Especially sprays low-level components are carefully crafted for excellent performance in high-load environments.
• * Light-weight *
  All dependencies are very carefully managed, sprays codebase itself is kept as lean as possible.
• * Modular *
  Being structured into a set of integrated but loosely coupled components your application only needs to depend onto the parts that are actually used.
• * Testable *
  All spray components are structured in a way that allows for easy and convenient testing.

Modules

• * spray-caching (快速、轻量的内存缓存*)
  Fast and lightweight in-memory caching built upon concurrentlinkedhashmap and Akka Futures.

• * spray-can (低级别、低开销、高性能* HTTP 服务器and客户端)
  A low-level, low-overhead, high-performance HTTP server and client built on top of spray-io.

• * spray-client (建立在*spray-can上，更高级别的客户端HTTP支持)
  Provides client-side HTTP support at a higher level than the low-level spray-can HTTP Client APIs, which it builds on.

• * spray-http * ()
  An immutable model of HTTP requests, responses and common headers. This module is completely stand-alone, it neither depends on Akka nor on any other part of spray.

• * spray-httpx (HTTP message工具 - 使用在 spray-client * and * spray-routing *)
  Higher-level tools for working with HTTP messages (mainly marshalling, unmarshalling and (de)compression) that are used by both spray-client as well as spray-routing.

• * spray-io (连接*Akka actors和Java NIO sockets的网络IO。被认为是Netty对Scala的基础版本)
  A low-level network IO layer for directly connecting Akka actors to asynchronous Java NIO sockets. We like to think of it a basic version of Netty for Scala. As of 1.0-M8/1.1-M8 it contains a backport of the new Akka IO layer coming with Akka 2.2. In 1.2-M8 it merely contains a few spray-specific “left-overs” that will likely go away completely in the future.

• * spray-servlet *
  An adapter layer providing (a subset of) the spray-can HTTP Server interface on top of the Servlet API. Enables the use of spray-routing in a servlet container.

• * spray-routing * (定义RESTful WS的DSL)
  A high-level routing DSL for elegantly defining RESTful web services.

• * spray-testkit (测试*spray-routing services的DSL)
  A DSL for easily testing spray-routing services. Supports both ScalaTest as well as Specs2.

• * spray-util * ()
  Small utility module used by all other modules except spray-http.

• * spray-json * (Scala的独立的JSON实现)
  A lightweight, clean and simple JSON implementation in Scala. Because it neither depends on any other part of spray nor on Akka and is only an optional dependency of spray-client and spray-httpx it doesn’t live in the main spray repository, but rather in its own github repository Note that you can easily use spray with whatever JSON library you like best, spray-json is just one of several alternatives.

Philosophy

Spray主要关注提供建立应用层工具，而不是应用核心。因此，它认为是一套==libraries，而不是framework==。

框架，对这个术语，我们的想法是，给你一个“框架”，在里面你创建你的应用。它的许多决策已经预先设置了，然后提供一个方法-其中包含了让你很快的开始和获得结果的支持架构。某种程度上，框架像一个骨瘦如柴的人，你给他喂食让他存活。因此，如果在你开始应用开发之前你选择它，它会工作的很好；在你前进的时候，试着紧跟着框架的“way of doing things”。
例如，你在创建一个浏览器方面的web app，选择一个web framework创建你的app就很合理；因为，app的核心是web服务器上你的代码与浏览器的交互。框架的创造者已经选择一种“久经考验”的方式去设计这个应用，让你在一种灵活“application-template”上做“填空”。依赖“最佳实践”的架构可以让事情做的更快。

然而，如果你的应用不主要是一个web app，它的核心不是浏览器交互，而是一些专业的、可能是复杂的业务服务，你只不过让它通过REST/HTTP接口连接到网络，web框架可能不是你需要的。在这种情况下，应用架构应该由“什么更有道理”而不是接口层来决定。当然，你可能不会从再从可能存在的浏览器特有的框架组件上获得益处-view templating, asset management,JavaScript- and CSS generation/manipulation/minification, localization support, AJAX support, etc.

Spray明确的被设计层“非框架”，不是因为我们不喜欢框架，而是为了一些不适合框架的案例。spray基于HTTP建立集成层最为理想，然后像这样的试着“保持观望”。==因此，一般不用在spray上建立app；而是当合理的时候在它上面建立应用，使用spray仅仅是为了HTTP集成的需要。==

Since its inception in early 2011 sprays development has been driven with a clear focus on providing tools for building integration layers rather than application cores. As such it regards itself as a suite of libraries rather than a framework.

A framework, as we’d like to think of the term, gives you a “frame”, in which you build your application. It comes with a lot of decisions already pre-made and provides a foundation including support structures that lets you get started and deliver results quickly. In a way a framework is like a skeleton onto which you put the “flesh” of your application in order to have it come alive. As such frameworks work best if you choose them before you start application development and try to stick to the frameworks “way of doing things” as you go along.

For example, if you are building a browser-facing web application it makes sense to choose a web framework and build your application on top of it because the “core” of the application is the interaction of a browser with your code on the web-server. The framework makers have chosen one “proven” way of designing such applications and let you “fill in the blanks” of a more or less flexible “application-template”. Being able to rely on best-practice architecture like this can be a great asset for getting things done quickly.

However, if your application is not primarily a web application because its core is not browser-interaction but some specialized maybe complex business service and you are merely trying to connect it to the world via a REST/HTTP interface a web-framework might not be what you need. In this case the application architecture should be dictated by what makes sense for the core not the interface layer. Also, you probably won’t benefit from the possibly existing browser-specific framework components like view templating, asset management, JavaScript- and CSS generation/manipulation/minification, localization support, AJAX support, etc.

spray was designed specifically as “not-a-framework”, not because we don’t like frameworks, but for use cases where a framework is not the right choice. spray is made for building integration layers based on HTTP and as such tries to “stay on the sidelines”. Therefore you normally don’t build your application “on top of” spray, but you build your application on top of whatever makes sense and use spray merely for the HTTP integration needs.