Silvia Puglisi - RESTful Rails Development: Building Open Applications and Services

by Silvia Puglisi

Copyright 2016 Silvia Puglisi. All rights reserved.

Printed in the United States of America.

Published by OReilly Media, Inc. , 1005 Gravenstein Highway North, Sebastopol, CA 95472.

OReilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://safaribooksonline.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com .

• Editors: Simon St. Laurent and Allyson MacDonald
• Production Editors: Colleen Lobner and
  Kristen Brown
• Copyeditor: Rachel Head
• Proofreader: Charles Roumeliotis
• Indexer: Ellen Troutman-Zaig
• Interior Designer: David Futato
• Cover Designer: Ellie Volckhausen
• Illustrator: Rebecca Demarest

• October 2015: First Edition

See http://oreilly.com/catalog/errata.csp?isbn=9781491910856 for release details.

The OReilly logo is a registered trademark of OReilly Media, Inc. RESTful Rails Development, the cover image of a Desmarests hutia, and related trade dress are trademarks of OReilly Media, Inc.

While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.

978-1-491-91085-6

[LSI]

This book is focused on designing and developing Representational State Transfer (REST) platforms in Rails. REST is the architectural style of the Web, consisting of a set of constraints that, applied to components, connectors, and data elements, constitute the wider distributed hypermedia system that we know today: the World Wide Web.

There are a few good reasons why it makes more sense to build platforms instead of just products or applications. Platforms are like ecosystems interconnecting different applications, services, users, developers, and partners. Platforms foster innovation through the inputs of their direct collaborators. By providing application programming interfaces (APIs) and software development kits (SDKs), platforms are more customer driven. Another reason for building platforms instead of just applications is that the Web is slowly but surely changing from a model in which a human reader would browse some content on web pages, to a model in which services and clients (not necessarily humans) exchange information. This was certainly, although only partially, what Tim Berners Lee envisioned in 2001 in his famous Scientific American article, The Semantic Web. The Web is becoming more semantic. In the past, a software agent would not have been able to understand an HTML document. It could parse some parts of it, but it would not process whether that document was referring to a blog post or something else, like the London bus schedule.

We used to think of the Web as hypertext documents linked to one another; nowadays web documents are instead becoming more like data objects linked to other objects, or hyperdata. Applications can either display hyperdata in a human-readable form or parse it so that other services or applications can consume that information. The Semantic Web can be easily explained by considering it as a normal evolution of hypertext. When hyperdata objects are explored through an API, different communication protocols are implemented to allow several technologies to access them independently. To enable this exchange of information among heterogeneous systems, the API implements a language-neutral message format to communicate. This might be XML or JSON, used as a container for the exchanged messages. If we think about it, a hypermedia API is one that is designed to be accessed and explored by any device or application. Its architecture is hence similar to the architecture of the Web and we apply the same reasoning when serving and consuming the API as when surfing a web page.

There are also reasons for choosing Rails over other web development frameworks. The first of them is having to develop in Ruby rather than another language. Ruby is easy to use, especially from a web developers perspective. It is totally object oriented and open source and has a vibrant community working on a variety of diverse and interesting projects and language libraries, making development easier. Ruby on Rails is a pragmatic framework, cleanly and perfectly implementing Model-View-Controller (MVC) patterns, which makes it easy to model real-world scenarios. Rails makes it easier to bootstrap an application, avoiding repetitive coding and speeding up feature development. Rails also follows agile methodology, promoting flexibility, evolutionary development, and iterative delivery.

This book wants to encourage developers to organically design platforms instead of products and to develop them quickly, in the hope that the new services added to the Web of tomorrow will be more easily discovered and eventually integrated, fostering open information exchange and stimulating partnerships between organizations. At the end of every chapter, the reader will have learned something new regarding how to build and organically extend a multiservice platform spanning different devices. Hopefully, at the end of this book you will have a better idea of how to build an architecture composed of different services accessing shared resources through a set of collaborating APIs and applications.