少有人走的路这篇讨论两个话题：
REST服务跟RESTful说的是同一个东西吗？
REST服务和RESTful在大多数情况下可以被视为同一个概念，但它们在具体的定义和用法上存在一些细微的差别。 REST服务的定义： REST服务是一种Web服务架构，其目标是为了创建具有良好扩展性的分布式系统。 REST服务基于客户/服务器模型，使用HTTP协议进行通信，并支持无状态、可缓存、层次化的系统设计。 REST服务允许客户端通过URI来访问和操作网络资源，使用HTTP方法（如GET、POST、PUT、DELETE）来执行对资源的操作。 RESTful的定义： RESTful是一种网络应用程序的设计风格和开发方式，它基于HTTP协议，并使用URI来指定资源。 RESTful是遵循REST架构约束条件和原则的应用程序或设计。满足这些约束条件和原则的应用程序或设计就被称为RESTful。 RESTful服务强调的是一种设计风格，而不是一种标准。它提供了一组设计原则和约束条件，用于指导如何构建REST服务。 REST服务与RESTful的关系： 在实际应用中，REST服务和RESTful经常被当作同一个概念来使用，因为它们都涉及到基于HTTP协议进行通信、 使用URI来指定资源、使用HTTP方法执行对资源的操作等。 然而，从严格意义上讲，REST服务是指一种具体的Web服务架构，而RESTful则更侧重于这种架构的设计风格和原则。 简单来说，可以认为REST服务是RESTful架构的一种具体实现方式，而RESTful则是对这种实现方式的一种抽象和概括。 总结： 总的来说，REST服务和RESTful在大多数情况下可以被视为同一个概念，它们都涉及到基于HTTP协议进行通信、使用URI来指定资源、 使用HTTP方法执行对资源的操作等。 但在具体使用时，REST服务更侧重于具体的实现方式和技术细节，而RESTful则更侧重于设计风格和原则。
那wcf可以实现rest服务，webapi不也可以实现rest吗？ 那既然wcf可以做，还要webapi干嘛 ？
确实，WCF（Windows Communication Foundation）和Web API都可以用来实现REST服务， 但它们在设计和用途上有一些显著的区别，这也是为什么尽管WCF可以做REST，但Web API仍然有其存在的价值和用途。 设计目标和定位： WCF：WCF是一个更为通用的框架，旨在支持广泛的通信协议和数据格式，包括SOAP、TCP、MSMQ等。 它最初是为构建RPC（远程过程调用）和SOAP服务而设计的，但也可以公开和使用REST服务。 WCF的复杂性和灵活性使得它适用于各种分布式系统和跨平台交互场景。 Web API：相比之下，Web API是一个专门为HTTP服务设计的框架，旨在简化构建RESTful Web服务的过程。 它更专注于HTTP协议和RESTful架构风格，提供了一套简洁的API来支持CRUD（创建、读取、更新、删除）操作。 易用性和简洁性： WCF：由于WCF的通用性和灵活性，它提供了更多的配置选项和扩展点，但同时也增加了使用的复杂性。 对于只需要构建REST服务的开发者来说，WCF可能过于庞大和复杂。 Web API：Web API的设计更加简洁和直观，它直接支持HTTP方法和URI路由，使得开发者能够更容易地构建RESTful服务。 此外，Web API还提供了与ASP.NET MVC的紧密集成，使得开发者能够利用现有的Web开发技能和工具。 社区支持和文档： WCF：尽管WCF是一个成熟的框架，但由于其复杂性和不断变化的技术趋势，WCF的社区支持和文档可能不如Web API丰富。 Web API：Web API作为ASP.NET MVC的一部分，得到了广泛的社区支持和丰富的文档资源。 这使得开发者能够更容易地找到解决方案、示例代码和最佳实践。 性能和可伸缩性： 在性能方面，Web API和WCF都可以实现高效的数据传输和处理。 然而，由于Web API更加专注于HTTP和RESTful架构风格，它可能在一些特定的Web应用场景中表现出更好的性能。 在可伸缩性方面，由于WCF支持多种通信协议和数据格式，它可能更适合于构建需要跨平台交互和复杂通信的分布式系统。 而Web API则更适合于构建基于HTTP的Web服务，如RESTful API。 未来发展： WCF：虽然WCF仍然是一个可用的框架，但随着技术的发展和新的通信协议的出现（如gRPC），WCF可能不再是未来技术发展的主要方向。 Web API：随着Web服务和云计算的普及，RESTful API的需求不断增长。 Web API作为ASP.NET Core的重要组成部分，将继续得到微软和社区的支持和更新，以满足不断变化的Web开发需求。 综上所述，尽管WCF和Web API都可以用来实现REST服务，但它们在设计目标、易用性、社区支持、性能和未来发展等方面存在差异。 因此，在选择使用哪个框架时，需要根据具体的应用场景和需求进行权衡和选择。
本文出自勇哥的网站《少有人走的路》wwww.skcircle.com，转载请注明出处！讨论可扫码加群：
