在技术发展的浪潮中，不断探索新的趋势和方法。最近，读到了一篇关于AJAX独立性的文章，这让思考了REST的概念以及它是如何简化服务器端技术，使得开发更加轻便。在以往的项目中，实现AJAX功能的“服务器页面”并不总是那么方便。为什么要纠结于视图状态这样的问题，而不是完全摒弃它呢？所需要的只是HTML、CSS和JavaScript，它们作为客户端能够消费服务。
认为，所熟知的MVC模式在某种程度上已经过时。仅仅替换薄视图以适应不同设备的想法，在理论上听起来不错，但实际上却是个笑话。现在，“构建Web应用程序”越来越意味着“将客户端应用程序集成到服务消费中”。过去听说过SOA，但需要设备市场的爆炸式增长，才能真正推动行业转向真正健壮的标准，而不是仅仅销售技术——本质上只是“相同事物的新版本”，并配备昂贵的工具来处理复杂性。尝试做SOA，然后是一些MVC与SOA部分共享模型，最终会得到一个紧密耦合的设计模式化结构（用不同的名字表示复杂性），或者如果敢于解耦，它可能会变得更加复杂。
假设需要构建一个基于一些初步讨论的Web应用程序，这些讨论最终并没有给出清晰的功能概述（这是常有的事），所以可以先构建一个不完整的骨架。处于第一个冲刺阶段...一些敏捷团队可能已经开始挣扎着交付“可用软件”...嗯，它的一些部分...然后随着需求的变化而进行大的调整...在大多数情况下，客户需要在拥有定制软件之前，先对自己的流程有一个更好的结构...越早得到更好的需求，成本就越低。大多数客户在真正投入之前都希望看到一些东西。如果能尽快提供一个实时网站，并让客户自己探索和感受，理解差距...那将是静态HTML本身，将用于进一步完成开发。
在客户端...现在大部分功能已经通过已经“移动”的静态HTML原型明确了，是时候进行更多的冲刺了。是时候在实时HTML上进一步进行Web设计了——不必再让Web设计师为ASP或JSP或PHP烦恼，因为他们通常“喜欢”HTML、CSS和PhotoShop，而且也不必再让开发人员疯狂地复制一些Web设计师的“疯狂想法”...在HTML上看起来很好，但从“X”服务器页面脚本内部来看却很可怕。只需完善Web设计，当“某些服务器端”可用时，添加AJAX调用层，做这些事情的人甚至不需要在同一个房间...沟通不好并不是坏事，只是想说事物可以多么解耦。
服务器端...一旦理解了数据库可能是什么样子，以及可能需要什么业务逻辑（即使在第一个冲刺阶段，与快速增长的静态HTML展示并行），就开始构建一个服务器端调用骨架，返回测试硬编码数据的方法，如果做TDD，就进行单元测试。目标是尽快提供服务器端以支持第一个AJAX调用...来自已经很好看的网站...然后再次回到客户端...他会对软件如何快速地根据他的需求定制而感到兴奋...并且会关注澄清所需要的一切。
现在大部分事情都很清楚了，所以只需要测试和完善应用程序，例如，交换尽可能短的JSON消息。如果客户突然发现他们会有比预期多1000倍的点击量...只需将服务器端部署到更大的机器、应用服务器或更好的操作系统上。
避免需求文档的负担，允许在实时组件上澄清功能：看到的就是得到的，这也是“得到”客户的一种好方法。
花哨的Web设计不再是学习开发人员的难题。
专注于以RESTful方式编写松散耦合的数据服务。为什么要浪费服务器资源来渲染“动态静态HTML”，当大部分时间可以避免它呢？如果真的想要，表示可以是HTML，但ROA服务器端最重要的是一个优雅的API，准备好被任何客户端消费，不仅仅是“网站”。
保持AJAX和JavaScript层简单。同时要注意不要使应用程序服务器膨胀。
尝试在服务器端进行TDD，这是一个API——客户会在截止日期前发现新的“愿望”...还能更好地依赖代码吗？
XML很棒，如果能减少数据库复杂性，或者可能需要应用一些XSL，但不要过度使用XML，JSON可能更好。
标准很好，但可能不需要SOAP，一个简单的HTTP servlet已经是一个服务了。不要在技术中淹没...这可以大大降低成本。