[getting started] Remove super-early mention of REST from Getting Started guide.

We will mention this as we introduce the routing components for Rails later on in the guide.

1 files changed, 1 insertions, 148 deletions

diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index dd1dd55f56..0fce4beae0 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -61,158 +61,11 @@ tremendous increase in productivity. If you persist in bringing old habits from
 other languages to your Rails development, and trying to use patterns you
 learned elsewhere, you may have a less happy experience.
 
-The Rails philosophy includes several guiding principles:
+The Rails philosophy includes two major guiding principles:
 
 * DRY - "Don't Repeat Yourself" - suggests that writing the same code over and over again is a bad thing.
 * Convention Over Configuration - means that Rails makes assumptions about what you want to do and how you're going to
 do it, rather than requiring you to specify every little thing through endless configuration files.
-* REST is the best pattern for web applications - organizing your application around resources and standard HTTP verbs
-is the fastest way to go.
-
-h4. The MVC Architecture
-
-At the core of Rails is the Model, View, Controller architecture, usually just
-called MVC. MVC benefits include:
-
-* Isolation of business logic from the user interface
-* Ease of keeping code DRY
-* Making it clear where different types of code belong for easier maintenance
-
-h5. Models
-
-A model represents the information (data) of the application and the rules to
-manipulate that data. In the case of Rails, models are primarily used for
-managing the rules of interaction with a corresponding database table. In most
-cases, each table in your database will correspond to one model in your
-application. The bulk of your application's business logic will be concentrated
-in the models.
-
-h5. Views
-
-Views represent the user interface of your application. In Rails, views are
-often HTML files with embedded Ruby code that perform tasks related solely to
-the presentation of the data. Views handle the job of providing data to the web
-browser or other tool that is used to make requests from your application.
-
-h5. Controllers
-
-Controllers provide the "glue" between models and views. In Rails, controllers
-are responsible for processing the incoming requests from the web browser,
-interrogating the models for data, and passing that data on to the views for
-presentation.
-
-h4. The Components of Rails
-
-Rails ships as many individual components.  Each of these components are briefly
-explained below.  If you are new to Rails, as you read this section, don't get
-hung up on the details of each component, as they will be explained in further
-detail later.  For instance, we will bring up Rack applications, but you don't
-need to know anything about them to continue with this guide.
-
-* Action Pack
-  ** Action Controller
-  ** Action Dispatch
-  ** Action View
-* Action Mailer
-* Active Model
-* Active Record
-* Active Resource
-* Active Support
-* Railties
-
-h5. Action Pack
-
-Action Pack is a single gem that contains Action Controller, Action View and
-Action Dispatch. The "VC" part of "MVC".
-
-h6. Action Controller
-
-Action Controller is the component that manages the controllers in a Rails
-application. The Action Controller framework processes incoming requests to a
-Rails application, extracts parameters, and dispatches them to the intended
-action.  Services provided by Action Controller include session management,
-template rendering, and redirect management.
-
-h6. Action View
-
-Action View manages the views of your Rails application. It can create both HTML
-and XML output by default. Action View manages rendering templates, including
-nested and partial templates, and includes built-in AJAX support.  View
-templates are covered in more detail in another guide called "Layouts and
-Rendering":layouts_and_rendering.html.
-
-h6. Action Dispatch
-
-Action Dispatch handles routing of web requests and dispatches them as you want,
-either to your application or any other Rack application.  Rack applications are
-a more advanced topic and are covered in a separate guide called "Rails on
-Rack":rails_on_rack.html.
-
-h5. Action Mailer
-
-Action Mailer is a framework for building e-mail services. You can use Action
-Mailer to receive and process incoming email and send simple plain text or
-complex multipart emails based on flexible templates.
-
-h5. Active Model
-
-Active Model provides a defined interface between the Action Pack gem services
-and Object Relationship Mapping gems such as Active Record. Active Model allows
-Rails to utilize other ORM frameworks in place of Active Record if your
-application needs this.
-
-h5. Active Record
-
-Active Record is the base for the models in a Rails application. It provides
-database independence, basic CRUD functionality, advanced finding capabilities,
-and the ability to relate models to one another, among other services.
-
-h5. Active Resource
-
-Active Resource provides a framework for managing the connection between
-business objects and RESTful web services. It implements a way to map web-based
-resources to local objects with CRUD semantics.
-
-h5. Active Support
-
-Active Support is an extensive collection of utility classes and standard Ruby
-library extensions that are used in Rails, both by the core code and by your
-applications.
-
-h5. Railties
-
-Railties is the core Rails code that builds new Rails applications and glues the
-various frameworks and plugins together in any Rails application.
-
-h4. REST
-
-Rest stands for Representational State Transfer and is the foundation of the
-RESTful architecture. This is generally considered to be Roy Fielding's doctoral
-thesis, "Architectural Styles and the Design of Network-based Software
-Architectures":http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm. While
-you can read through the thesis, REST in terms of Rails boils down to two main
-principles:
-
-* Using resource identifiers such as URLs to represent resources.
-* Transferring representations of the state of that resource between system components.
-
-For example, the following HTTP request:
-
-<tt>DELETE /photos/17</tt>
-
-would be understood to refer to a photo resource with the ID of 17, and to
-indicate a desired action - deleting that resource. REST is a natural style for
-the architecture of web applications, and Rails hooks into this shielding you
-from many of the RESTful complexities and browser quirks.
-
-If you'd like more details on REST as an architectural style, these resources
-are more approachable than Fielding's thesis:
-
-* "A Brief Introduction to REST":http://www.infoq.com/articles/rest-introduction by Stefan Tilkov
-* "An Introduction to REST":http://bitworking.org/news/373/An-Introduction-to-REST (video tutorial) by Joe Gregorio
-* "Representational State Transfer":http://en.wikipedia.org/wiki/Representational_State_Transfer article in Wikipedia
-* "How to GET a Cup of Coffee":http://www.infoq.com/articles/webber-rest-workflow by Jim Webber, Savas Parastatidis &
-Ian Robinson
 
 h3. Creating a New Rails Project