Seamless EDI implementation through Web Services
EDI is used almost everywhere regardless of industry or company size. The most extensive use of EDI is in the retail industry. EDI compliance is mandatory in order to trade with big retailers such as Target, Costco, Walmart,… even giants of electronic commerce like Amazon are heavy users of EDI.
There are a lot of different types and approach of implementing EDI in your company. It can fully managed EDI service, or gaining popularity lately EDI Web Service, because, service architects and developers want EDI to be easy to implement, maintainable, extensible, and scalable.
What is web service?
Web service is a network technology that provides inter-program interaction based on web standards. More specifically, it’s client and server application that communicate over the World Wide Web’s (WWW).
The W3C consortium defines a web service as: “A Web service is a software system designed to support interoperable machine-to-machine interaction over a network”.
Thus, the web service is identified by a URI string. The Web service has a User Programmatic Interface (UPI) that is represented in WSDL format. Other systems interact with this web service by exchanging SOAP or REST protocol messages. HTTP Hypertext Transfer Protocol is used to transport the messages. The description of Web services and their APIs can be found by UDDI.
♦ WSDL (Web Services Description Language) – is an XML-based interface definition language that is used for describing the functionality offered by a web service.
♦ UDDI (Universal Discovery, Description and Integration) – is an XML-based registry for business internet services
Web services are rich in functionality and extensibility, as well as their machine-readable descriptions through the use of XML. Web services can be combined to achieve complex operations.
The diagram above shows a very simplified view of how a web service works. The client invokes a web service call by sending a request to a server which hosts the actual web service, then get the response from the web service.
What are different types of web services?
Web services can be deployed in several ways. The following web-services are the most commonly used http web services:
♦ SOAP(Simple Object Access Protocol) — in fact, it is a triple of standards SOAP/WSDL/UDDI
♦ REST(Representational State Transfer) – quite often called as RESTful API (Application Program Interface that uses HTTP requests to GET, PUT, POST and DELETE data) or RESTful web service – is based on (REST) technology.
Actually, SOAP originated from XML-RPC (XML Remote Procedure Call) and is the next generation of its development and evolution. While REST is a concept, based on an architectural style.
Of course, there are other types of web services, but since they are not widely used, we will focus on these two in this brief review: SOAP and REST.
A Quick Overview of SOAP Web Services
SOAP stands for Simple Object Access Protocol. It is an XML-based protocol for accessing web services.
It is platform and language independent. It means that by using SOAP, you can interact with other programming language applications.
Initially, SOAP was primarily intended to implement a remote procedure call (RPC). Now SOAP is used to exchange arbitrary messages in XML format, not just to call procedures.
Like any text protocol, SOAP can be used with any application layer protocol: SMTP, FTP, HTTPS, etc., but more often SOAP is used over HTTP.
All SOAP messages are structured as an envelope (is the root element in every SOAP message), including the following elements:
- Message ID (local name)
- Optional Header element
- Mandatory Body element (message body)
Structure of SOAP message:
The expanded list of SOAP message elements is shown in the data schema (for SOAP version 1.2).
A Quick Overview of REST Web Services
REST stands for Representational State Transfer. As it was mentioned above, REST is not a protocol but an architectural style built on existing standards that are well known and controlled by the W3C consortium, such as HTTP, URI (Uniform Resource Identifier), XML and RDF (Resource Description Format).
In a REST services, the emphasis is placed on access to resources, and not on the execution of remote services; this is the fundamental difference from SOAP-services. However, the remote procedure call is also applicable to REST. It uses the PUT, GET, POST, and DELETE methods of the HTTP protocol to perform tasks. The cardinal difference between REST and SOAP is that REST remains an HTTP request.
According to many developers, SOAP is cumbersome and difficult to use. REST is an easy alternative.
REST is using the URL approach. Often, to make a request, REST relies on a simple URL Instead of using XML.
Advantages of REST Web Services
REST is more flexible and easier to use for the most part. There are following advantages when:
- Agile: Unlike SOAP, there is no strict specification for REST Web services and it consumes less bandwidth and resources, thus, REST Web services are very fast.
- Language and Platform independent: REST web services can be written in any programming language and run on any platform.
- Can be used with different data format: REST web service permits different data format such as Plain Text, XML, HTML, and JSON.
SOAP vs REST what to choose?
SOAP is more applicable in complex architectures where interaction with objects is beyond the scope of the CRUD model. In applications having the CRUD model, it can be quite applicable to REST due to its simplicity and transparency.
In fact, if any objects in your service do not need a complex relationship than: “Create”, “Read”, “Update”, “Delete” (usually in 99% of cases is enough), it is possible that REST will be the best choice.
In addition, REST compared to SOAP can be more productive because it does not require parsing complex XML commands on the server (regular HTTP requests are performed — PUT, GET, POST, DELETE).