Magento 2 - Between "Rest" and "Soap", Which is better then one?

Question

Between "Rest" and "Soap" API, Which is better then one ?
I have some cases below:
1) Apply for mobile app call web-service.
2) Apply for desktop app call web-service.
3) Apply for web app call web-service.
Of course, In magento 2, I need to know:
1) How to config only use only one "Rest" or "Soap"?
2) How to create new web-service ?
Thanks!

Answer 1

If you use static typed approach than use SOAP. In other cases use Rest.

Currently all services available over Rest and SOAP transport, you cannot configure this.

To create new service you need create service interface and expose it through configuration. See official documentation for it.

Answer 2

Smaller learning curve => REST Fast and Adapt to Programings => REST

Answer 3

There is no definitive answer as to which is better, REST or SOAP, as it ultimately depends on your specific use case and requirements. Here are some points to consider when deciding which to use:

REST (Representational State Transfer) is a simple, lightweight, and flexible architecture that is well-suited for building APIs that expose resources and enable communication over HTTP. REST APIs are easy to understand and use, and they are widely supported by a variety of platforms and languages.

SOAP (Simple Object Access Protocol) is a more heavy-duty protocol that was designed to support complex, enterprise-level applications. SOAP uses XML to encode its messages, which makes it more verbose and less efficient than REST. However, SOAP has a number of features that make it well-suited for certain use cases, such as its ability to support multiple encoding styles, its built-in error handling, and its support for WS-* (Web Services) extensions.

Here are some considerations for each of your specific use cases:

If you are building a mobile app that needs to call a web service, REST is probably the better choice. REST is simple, lightweight, and easy to use, which makes it well-suited for mobile app development.

If you are building a desktop app that needs to call a web service, either REST or SOAP could be a good choice, depending on your specific requirements. If you need a more feature-rich and complex API, SOAP might be the better choice. If you need a simple, lightweight API, REST might be a better fit.

If you are building a web app that needs to call a web service, either REST or SOAP could be a good choice, depending on your specific requirements. Again, if you need a more feature-rich and complex API, SOAP might be the better choice. If you need a simple, lightweight API, REST might be a better fit.

As for configuring Magento 2 to use only one type of API (either REST or SOAP), you can follow these steps:

In the Magento admin panel, go to Stores > Settings > Configuration.
In the left-hand menu, expand the Services section and click on SOAP/XML-RPC Roles.
In the API Roles Settings section, set the "API Role Resources" field to either "All" or "Custom".
If you set the field to "Custom", you can then use the checkboxes to select which API resources should be available.
Click on the Save Config button to save your changes.

To create a new web service in Magento 2, you can follow these steps:

In the Magento admin panel, go to System > Web Services > SOAP/XML-RPC - Roles.
Click on the Add New Role button.
Enter a name for the role and a description (optional).
In the Role Resources section, use the checkboxes to select the resources that should be available to the role.
Click on the Save Role button to save the new role.

I hope this helps!

Answer 4

Comparing SOAP vs REST API, SOAP only works with XML formats whereas REST work with plain text, XML, HTML and JSON.

• SOAP needs more bandwidth for its usage whereas REST doesn’t need much bandwidth

(Dis-)advantages of SOAP:

• well-defined web-service
• has pre-built standards (SOAPv1, SOAPv2, SOAPv2 WS-I)
• works well in enterprise environments (due to standards)
• some tools can be automated by using the WSDL
• heavyweight compared to REST.

(Dis-)advantages of REST:

• easier to use
• more flexible
• smaller learning curve
• effictient/lightweight compared to SOAP
• no defined web-service structure (no WSDL)

Answer 5

When to use REST?
One of the most highly debatable topics is when REST should be used or when to use SOAP while designing web services. Below are some of the key factors that determine when REST and SOAP API technology should be used for web services REST services should be used in the following instances,

1. Limited resources and bandwidth – Since SOAP messages are heavier in content and consume a far greater bandwidth, REST should be used in instances where network bandwidth is a constraint.
2. Statelessness – If there is no need to maintain a state of information from one request to another then REST should be used. If you need a proper information flow wherein some information from one request needs to flow into another then SOAP is more suited for that purpose. We can take the example of any online purchasing site. These sites normally need the user first to add items which need to be purchased to a cart. All of the cart items are then transferred to the payment page in order to complete the purchase. This is an example of an application which needs the state feature. The state of the cart items needs to be transferred to the payment page for further processing.
3. Caching – If there is a need to cache a lot of requests then REST is the perfect solution. At times, clients could request for the same resource multiple times. This can increase the number of requests which are sent to the server. By implementing a cache, the most frequent queries results can be stored in an intermediate location. So whenever the client requests for a resource, it will first check the cache. If the resources exist then, it will not proceed to the server. So caching can help in minimizing the amount of trips which are made to the web server.
4. Ease of coding – Coding REST Services and subsequent implementation is far easier than SOAP. So if a quick win solution is required for web services, then REST is the way to go.

When to use SOAP?

1. SOAP should be used in the following instances, Asynchronous processing and subsequent invocation – if there is a requirement that the client needs a guaranteed level of reliability and security then the new SOAP standard of SOAP 1.2 provides a lot of additional features, especially when it comes to security.
2. A Formal means of communication – if both the client and server have an agreement on the exchange format then SOAP 1.2 gives the rigid specifications for this type of interaction. An example is an online purchasing site in which users add items to a cart before the payment is made. Let’s assume we have a web service that does the final payment. There can be a firm agreement that the web service will only accept the cart item name, unit price, and quantity. If such a scenario exists then, it’s always better to use the SOAP protocol.
3. Stateful operations – if the application has a requirement that state needs to be maintained from one request to another, then the SOAP 1.2 standard provides the WS* structure to support such requirements.

Challenges(Limitation with the SOAP API)

1. WSDL file – One of the key challenges of the SOAP API is the WSDL document itself. The WSDL document is what tells the client of all the operations that can be performed by the web service. The WSDL document will contain all information such as the data types being used in the SOAP messages and what all operations are available via the web service. The below code snippet is just part of a sample WSDL file.
2. Document size – The other key challenge is the size of the SOAP messages which get transferred from the client to the server. Because of the large messages, using SOAP in places where bandwidth is a constraint can be a big issue.

Challenges in REST API

1. Lack of Security – REST does not impose any sort of security like SOAP. This is why REST is very appropriate for public available URL’s, but when it comes down to confidential data being passed between the client and the server, REST is the worst mechanism to be used for web services.
2. Lack of state – Most web applications require a stateful mechanism. For example, if you had a purchasing site which had the mechanism of having a shopping cart, it is required to know the number of items in the shopping cart before the actual purchase is made. Unfortunately, the burden of maintaining this state lies with the client, which just makes the client application heavier and difficult to maintain.