Representational state transfer (REST)
Representational state transfer (REST) is a software architectural style consisting of a coordinated set of architectural constraints applied to components, connectors, and data elements, within a distributed hypermedia system. REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements.
The term representational state transfer was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation at UC Irvine. REST has been applied to describe desired web architecture, to identify existing problems, to compare alternative solutions, and to ensure that protocol extensions would not violate the core constraints that make the web successful. Fielding used REST to design HTTP 1.1 and Uniform Resource Identifiers (URI). The REST architectural style is also applied to the development of web services as an alternative to other distributed-computing specifications such as SOAP.
Architectural constraints
- Client–server
- Stateless
- Cacheable
- Layered system
- Code on demand (optional)
- Uniform interface
Representational state transfer (REST)
Create, read, update and delete (CRUD)
Create, read, update and delete (CRUD)
Service-oriented architecture (SOA)
Service-oriented architecture (SOA) is a software design and software architecture design pattern based on discrete pieces of software providing application functionality as services to other applications. This is known as service-orientation
A service is a self-contained unit of functionality, such as retrieving an online bank statement. Services can be combined by other software applications to provide the complete functionality of a large software application. SOA makes it easy for computers connected over a network to cooperate. Every computer can run an arbitrary number of services, and each service is built in a way that ensures that the service can exchange information with any other service in the network without human interaction and without the need to make changes to the underlying program itself.
Design concept
SOA is based on the concept of a service. Depending on the taken service design approach, each SOA service is designed to perform one or more activities by implementing one or more service operations. As a result, each service is built as a discrete piece of code. This makes it possible to reuse the code in different ways throughout the application by changing only the way an individual service interoperates with other services that make up the application, versus making code changes to the service itself. SOA design principles are used during software development and integration.
For some, SOA can be seen in a continuum from older concepts of distributed computing and modular programming, through SOA, and on to current practices of mashups, SaaS, and cloud computing (which some see as the offspring of SOA)
Other SOA concepts
Architectures can operate independently of specific technologies and can therefore be implemented using a wide range of technologies, including:
- SOAP, RPC
- REST
- CORBA
- Web services
- DDS
- Java RMI
- WCF (Microsoft’s implementation of web services now forms a part of WCF)
- Apache Thrift
- SORCER