The Definitive Guide to Yii 2.0
This tutorial is released under the Terms of Yii Documentation.
All Rights Reserved.
2014 (c) Yii Software LLC.
- Getting Started
- Application Structure
- Handling Requests
- Key Concepts
- Working with Databases
- Getting Data from Users
- Displaying Data
- RESTful Web Services
- Development Tools
- Special Topics
API documentation generator for Yii 2
This extension provides an API documentation generator for the Yii framework 2.0.
For license information check the LICENSE-file.
Gii Extension for Yii 2
This extension provides a Web-based code generator, called Gii, for Yii 2 applications. You can use Gii to quickly generate models, forms, modules, CRUD, etc.
Debug Extension for Yii 2
This extension provides a debugger for Yii 2 applications. When this extension is used, a debugger toolbar will appear at the bottom of every page. The extension also provides a set of standalone pages to display more detailed debug information.
The toolbar displays information about the currently opened page, while the debugger can be used to analyze data you've previously collected (i.e., to confirm the values of variables).
When handling a RESTful API request, if there is an error in the user request or if something unexpected happens on the server, you may simply throw an exception to notify the user that something went wrong. If you can identify the cause of the error (e.g., the requested resource does not exist), you should consider throwing an exception along with a proper HTTP status code (e.g., [[yii\web\NotFoundHttpException]] represents a 404 status code). Yii will send the response along with the corresponding HTTP status code and text. Yii will also include the serialized representation of the exception in the response body. For example:
A good API is versioned: changes and new features are implemented in new versions of the API instead of continually altering just one version. Unlike Web applications, with which you have full control of both the client-side and server-side code, APIs are meant to be used by clients beyond your control. For this reason, backward compatibility (BC) of the APIs should be maintained whenever possible. If a change that may break BC is necessary, you should introduce it in new version of the API, and bump up the version number. Existing clients can continue to use the old, working version of the API; and new or upgraded clients can get the new functionality in the new API version.
To prevent abuse, you should consider adding rate limiting to your APIs. For example, you may want to limit the API usage of each user to be at most 100 API calls within a period of 10 minutes. If too many requests are received from a user within the stated period of the time, a response with status code 429 (meaning "Too Many Requests") should be returned.
Introduction Article Count: 2
Getting Started Article Count: 8
Application Structure Article Count: 12
Handling Requests Article Count: 8
Key Concepts Article Count: 9
Working with Databases Article Count: 8
Getting Data from Users Article Count: 6
Displaying Data Article Count: 7
Security Article Count: 7
Caching Article Count: 5
RESTful Web Services Article Count: 9
Development Tools Article Count: 3
Testing Article Count: 6
Special Topics Article Count: 12
Widgets Article Count: 2
Helpers Article Count: 4
Page 5 of 18