Book Image

Zend Framework 2 Application Development

By : Christopher Valles
Book Image

Zend Framework 2 Application Development

By: Christopher Valles

Overview of this book

<p>Zend Framework 2 has a flexible architecture that lets us build modern web applications and web services easily. It also provides an easy-to-use, high quality component library that is designed to be used the way you want. It's easy to get started and produce a powerful and professional looking website with Zend Framework 2 Application Development. Exploring real life applications, we will explore the Zend Framework 2 components, as well as throwing some light on best practices and design concerns faced when building complex MVC applications.Zend Framework 2 Application Development is a hands-on guide to building your application. We will explore the components of this new version of the framework and discover how to use each component, the options available, and how to get the most from each component. Whilst learning everything you need to know, we’ll even create our own social network. We will also learn to engineer an application using an API-centric approach, broadly used today to build applications that work seamlessly on desktops, mobiles and tablets. We will learn how to filter and validate data, interact with databases to retrieve and store data, handle and manipulate file uploads, interact with other websites, deal with spam, and also protect your APIs using OAuth authentication whilst allowing people from all over the world to interact with your application. Zend Framework 2 Application Development is your guide to everything you need to know to build applications of any size for big and small companies alike, whilst using the right components for the job.</p>
Table of Contents (21 chapters)
Zend Framework 2 Application Development
Credits
About the Author
Acknowledgments
About the Reviewers
www.PacktPub.com
Preface
4
The First Request/Response – Building the User Wall
5
Handling Text Content – Posting Text
6
Working with Images – Publishing Pictures
8
Dealing with Spam – Akismet to the Rescue
Index

The approach – API-centric app


To build the social network, we will use an approach called API-centric. First of all, for those who are unfamiliar with the term API, it is an interface that we build to expose functionality. By doing this, we allow other applications to interact with us. For example, a news website can expose an API to allow people to retrieve articles from their archive by specifying the date of the article, the author, and so on.

An API-centric application is an application that executes all functionality that make calls to an internal API. For example, if a user on our social network is going to post a picture, our app will pass the image and details of the user to the API to execute the actual steps needed to store the image and publish it on the user profile.

The API-centric architecture looks like the following figure:

As you can see, API is the central point and everything else is built around it. The web app, the mac app, and so on are the clients that consume API. Now, let's compare the lifecycle of a request between an app-centric approach and a traditional model.

As you can see, in the traditional model you made requests directly to the server. The server in this case contains the logic of the client and also the business logic. In the API-centric model, the request is made from the browse to the client app; this application can be on the same server as the API or on a separate machine. Then, the client app will issue a request to the API. After this, the request will go back to the client app and finally to the user. In this case, we are separating the code of the client app from the code of the API. The client app acts as a proxy for the API that has the business logic. Note that the image doesn't represent the time spent on the request.

Since the explosive increase in the usage of smartphones, an increasing number of web applications have ended up with an application on the phone. Some of themjust adapt the website to the phone screen size by removing or redesigning the interface, while others choose to build a native application that will run on the phone of the visitor.

The first benefit of this approach for our social network is that the core of the application is just an API and all the related clients will rely on it to use the functionality. This means we have a good separation of concerns, and we will have separated the business logic from the client logic. This will allow us to create a website to access the service and the possibility of building a native application for mobile phones or even a desktop program using the same API in future.

The second benefit is that the API is stateless; this means that the calls made to the API will not include anything about the session, and there is no session handling/management involved. This sounds wrong at the beginning but allows the developer to build a RESTful API that will not rely on the state of the user session or data stored on the session.

Note

RESTful is the application of the REST architecture in web services. REST is an architectural style for designing networked applications. The idea behind it is to avoid complex mechanisms and use plain HTTP. A typical RESTful web service will use HTTP to do the four CRUD (Create, Retrieve, Update, and Delete) operations.

Another benefit is that the code can be tested further as you don't have to recreate the whole user session in order to test a functionality.

If we take a look at this approach from the server-side point of view, we can see some benefits; as we are separating the responsibilities of every component, we can assign different machines and resources to each of them. This way of organizing the servers allows us also to scale the components we need independent of the others.

One downside of the approach we can easily see is that if the API goes down, everything will go down and the clients will not be able to do anything.