第一次使用已经过证明的模式和听起来不错的最佳实践，进行适当地软件开发时的好处之一是，在软件中解决核心需求时，许多非功能性的需求也得到了初步解决。 

　　一个火箭科学家曾经耐心地对一个新的软件开发员解释，为什么一个精确的起始点很重要。对着一个假想天体，他说“即使错误一度，将会使我们完全错过我们的目标。”另一个人以类似的方式进行了补充，“即使我们做的事情完全正确，也会有意想不到事情，这些事情看起来进行的很好。”因此，有了面向服务和安全，当我们设计合适的服务时，非功能性需求，如安全，都会顾好他们自己的。　　

意外但有益的结果

　　面向服务软件的一个标准的最佳实践是，给客户提供代表响应单元的多个方法。这一最佳实践意图改进web服务交付的质量，同时也带来了意想不到的好处：提升了我们开发的应用安全性。

　　以最坏的情况想象一下应用安全性：理解设计一个简单的、单一的、无状态请求或响应单元，调用经典的RU，轻松地提供了一个一体化的，可能会成为系统攻击的密码。当使用单一键时，事情会变得更糟。而拦截100个HTTPS RU可能很难打破，但有1,000,000可以使证书逆向工程容易多了。

　　事实上，密码破解的第一个规则是有共同性的——寻找重复的模式。因此，要避免一次又一次地向请求发送完全相同的元数据。总之，破解密码时需要做的是有足够觉的关键字，来寻找这样的预期，标准，SOAP信封。每次都在同一位置放置足够的标志，然而这样还是有可能会遗漏加密一些东西。

　　所以，即使是从安全的方面考虑，提供两个代表RU方法比只提供一个要好。因此，提供多于一个的代表所有服务请求的方法的实践，应该会被看作是一个安全的最佳实践。提供多个证明对所有事情都没有坏处，可能只除了缓存和性能。在许多方面，提供对多个、不同的RU编码的支持，只是对适当的服务版本控制（SVC）的一个扩展。

　　事实上，当我们开放自己，接受向同一服务提交多个RU版本后，随着时间的推移，数据转换往往会变得更安全，当应用程序使用模式和最佳实践设计合理后进行展示，许多非功能性需求都会顾全自己的。