API priority architecture or FAT thin server contention

Since 2007 http://www.aliyun.com/zixun/aggregation/5541.html ">apple released the iphone, Web apps and Web sites have significantly increased their chances of appearing on small screens, Thus the major websites and organizations have to make appropriate changes to their applications. However, given the volume of data, application extensibility, and the release and maintenance of new features, the architecture of the application has to be changed on demand, such as Twitter's service-oriented. Recently, Leaseweblabs published an article detailing the API priority architecture.


the following:


in the API precedence architecture, API users are treated as the primary users of the application. This means that the API is no longer an alternative to view in MVC, and it will have the highest priority. The main difference is that in API first, the schema always executes a complete, responsive, and documented API. This is especially important when the target is directed to mobile (the application is connected to the API), the agent (the presentation layer uses the API), and a highly integrated, decoupled, multiple-product environment.


MVC

The
MVC architecture has been in vogue for a long time, and MVC has become increasingly hot since Ror was released in 2004. In the case of MVC, users and employees use two different parts of the front-end and back-end to dramatically increase the reuse rate of components in the application. The appropriate use of the MVC strategy allows many parts of the application to be reused, including Dbal/orm, Business Logic, presentation, and AAA. AAA (authentication, Authorization, Accounting) allows employees to simulate user behavior, using the same login interface and shared log devices.

View layer in
move


in 2007, Apple released the iphone, and the display of Web apps (and Web sites) on small screens has risen rapidly. At the same time MVC's compatibility with small screen has been very good, need to do is to open a mobile phone or flat panel on the view layer and make related adjustments. This strategy, which builds a separate view layer, is called "mobile One" and is the most cost-effective and radical way to modify it. Another alternative is to create two view tiers: one for mobile devices and another for desktop devices. The moving end is usually "M." The beginning of the sub domain name (such as m.csdn.net), very simple and intuitive one way.


Adding API
to MVC

"HTML5 vs 820.html" >native "application development is a raging battle, citing Danny Brown:


when companies are building mobile apps, they face an important choice, native or HTML5. Each solution has its own advantages, but the wrong choice will pay dearly.


Select native requires a complete, responsive, and documented API, but selecting HTML5 only needs to redesign the view layer. Each scheme has its own advantages, only the corresponding scenarios will be the outcome of the score. The so-called existence makes sense, and no solution is ever a loser: Create an API as a view on MVC. Let's take a look at why many people have chosen another.


First, the MVC approach requires 200ms of page load time. In this way, the server does 3 things: Database abstraction, business logic, and rendering, which is why it is called Fat server. The API does not assume rendering work, only executes the smaller business logic for each request, and is therefore named thin server. A good API is highly optimized and typically loads less than 20ms. This means that when multiple calls are performed (up to 10), the rendering time for a full page does not exceed 300ms.


now, if you're using MVC and you're missing 1 APIs, the easiest thing to do is to add some view to output JSON and call it the "restful API," and all you have to do is write some documents and please the boss. In fact, throughout the cycle, this API is completely unavailable, because it is not extensible, but also slow and terrible.


Twitter and API priority Architecture


in 2010, Twitter unveiled their "API-a-a" strategy. Since its application uses JavaScript, it is called a JavaScript schema, similar to the architecture of mobile applications. This allows them to fully reuse the existing APIs, which are used at the start, and are the basis for application in later development cycles. By using a RESTful JSON API, their APIs focus on the best integration of JavaScript applications. But Twitter also uses traditional pages to support its apps, which they have published:


To support crawler and users without JavaScript, we need to run 1 rendering systems on both the server and the client.


uses traditional web-page delivery and API-first policies, which are simply called "Hybrid". The following diagram lists different approaches:


Conclusion


optimization reuse can reduce costs, but only with strong architectural policies. While reorganizing code to increase architectural compliance (compliance) does not directly bring value to the business, it can reduce the cost of applying future revisions, but this level of persuasion is clearly difficult to reach.