Tag Archive for: SOAP

SOAP or REST Web Services: what you should use for EDI implementation?


This post was updated to reflect current trends and information.


In my previous article Seamless EDI implementation through Web Services, I covered various types of web services. Perhaps, if you’re still worried about choosing between SOAP or REST for your EDI implementation, this brief comparative review should help you make a choice. But in any case, you should remember that the focus of your decision must concentrate on which web service best responds to your needs.

First, look at the difference between the SOAP and REST request and response packets.

Here is a SOAP request and response packets:

SOAP request sample

SOAP response sample

Here is a REST request and response:

REST sample request and response

What is difference between SOAP and REST Web services?

1. SOAP actively uses XML to encode requests and responses, as well as strong data typing, ensuring the integrity of the information is intact, during transmission between the client and the server. On the other hand, requests and responses in REST can be transmitted in ASCII, XML, JSON or any other formats that can be recognized by both the client and the server. In addition, there are no built-in data type requirements in the REST model. As a result, the request and response packets in REST are much smaller than their corresponding SOAP packets.

2. In the SOAP model, the HTTP data transfer layer is a “passive observer,” and its role is limited to sending SOAP requests from a client to the server using the POST method. Service request details, such as the remote procedure name and input arguments, are encoded in the request body. Opposite of SOAP the REST architecture, considers the HTTP data transfer layer as an active participant in an interaction using existing HTTP methods, such as GET, POST, PUT, and DELETE, to indicate the type of service requested. Therefore, from a developer’s perspective, REST requests are generally simpler to be formulated and understood since they use existing and well-understood HTTP interfaces.

3. The SOAP model allows service developers to describe its APIs in a Web Service Description Language (WSDL) file format. Creating these files is quite difficult, but it’s well worth the effort since SOAP clients can automatically retrieve detailed information from these files. For example, about the names and method signatures, input and output types and return values. On the other hand, the REST model avoids the complexity of WSDL in favor of a more intuitive interface based on the standard HTTP methods described above.

4. At the “heart” of REST is the concept of resources, while SOAP uses interfaces based on objects and methods. The SOAP interface can contain an almost unlimited number of methods; the REST interface, in contrast, is limited to four possible operations, corresponding to the four HTTP methods.

Useful link: Download EDI Web Service overview. 

This EDI Web Service overview covers the following topics:

  • What is EDI2XML Web Services?
  • Advantages of using EDI2XML HTTP service
  • Who is EDI Web Service for?

The best Web Service for EDI

EDI2XML Web Service, is for developers, systems integrators and businesses, interested in building their own EDI (Electronic Data Interchange) integration flows and programs. Normally, these individuals, are capable of interacting with external API and Web Services to translate EDI to XML and XML to EDI, and have the resources and expertise to work with Web Services and HTTP requests in order to achieve their goals. EDI2XML web service, is the premier choice for IT people as a reliable service to accomplish such Integration projects.

The best way to discover how REST works for EDI is to try our free 15- days trial version of EDI2XML Web Service.

Click here to request the price list in order to access EDI2XML Web Service

 

EDI Web Service for edi integration

Continue Reading About Web Service: 

 

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.

web service diagram

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:

SOAP message structure

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).

EDI2XML HTTP service

EDI2XML Web Service, is an HTTP (based on REST) service running over the internet, on EDI2XML private cloud platform that is capable of receiving HTTP requests to translate EDI messages to XML, and XML messages to EDI (based on EDI2XML’s proprietary XML format). Advantages of using EDI2XML HTTP service:

⇒ You can start with less than an hour

⇒ No contract: pay as you go

⇒ Very simple and dynamic pricing scheme

⇒ Availability and reliability

⇒ Based on proven technology in the field for over 18 years now

⇒ Outstanding technical support

Our EDI Web Service solution solves developer’s problem because we have over 18 years of expertise in EDI, that is difficult for every developer and integrator to acquire quickly.

You can start with the free 15 – days trial of EDI2XML Web Service to see how real-time translation services works.

EDI Web Service for edi integration

Related Posts:

What is EDIFACT? | UN / EDIFACT standard overview

EDI ANSI ASC X12 Standards – Technical Overview – 2020

EDI Integration of B2B e-commerce for small companies