There are some good answers already. This is what what my advice would be:

1. If you are connecting to an app that already has a way to integrate with it (OData, REST or SOAP), choose that.
2. If you need to share data, use what Studio Pro calls a published OData service. This gives a very flexible REST service, with all the advantages of REST mentioned above. It's also an OData service, so clients that can consume OData can offer an even better experience. One such example is Studio Pro itself: external entities are a straightforward way to consume OData services.
3. If you can't use a published OData service for some reason, use what Studio Pro calls a published REST service.

Hi Tjark,

Webservice is for API which uses SOAP protocol whereas REST is a protocol and hence we work with APIs which support REST protocol.

Tbh, modern technologies/platforms prefer to implement REST over soap because of simplicity and flexibility.

But SOAP API protocol integration will take place over old technologies like SAP.

Regards,

Naman Khard

I agree with Naman, extending the answer using ChatGPT:

The choice between SOAP (Simple Object Access Protocol) and REST (Representational State Transfer) in web development depends on various factors, and there isn't a one-size-fits-all answer. Here are some scenarios where you might prefer one over the other:

Choose SOAP when:

1. Formal Contracts and Strong Typing are Required:

   • SOAP relies on XML-based contracts (WSDL - Web Services Description Language) that provide a strict definition of the message structure, which can be useful in scenarios where a formal contract with strong typing is essential.

2. Built-in Security:

   • SOAP has built-in security features, such as WS-Security, which provides a standardized way to secure web services. If your application demands a high level of security, SOAP may be a better choice.

3. ACID Compliance:

   • If your application requires ACID compliance (Atomicity, Consistency, Isolation, Durability), SOAP-based web services might be more appropriate. SOAP supports transactions, ensuring data consistency.

4. Asynchronous Processing:

   • If your application needs support for asynchronous processing and you require features like queuing and reliable message delivery, SOAP provides a more structured approach for these scenarios.

Choose REST when:

1. Simplicity and Ease of Use:

   • REST is known for its simplicity and ease of use. If your application is lightweight and doesn't require the formality of SOAP, REST might be a more straightforward option.

2. Resource-Centric:

   • REST is resource-centric, and it maps well to the principles of the web. If your API is exposing resources that can be identified by URLs and manipulated using standard HTTP methods, REST is a natural fit.

3. Statelessness:

   • REST is stateless, meaning each request from a client contains all the information needed to understand and fulfill the request. If statelessness aligns well with your application's requirements, REST is a good choice.

4. Performance and Scalability:

   • RESTful services are often considered more lightweight and scalable compared to SOAP. If your application is focused on performance and scalability, REST might be a better fit.

Rule of Thumb:

• Use REST:

  • For public APIs and when simplicity, scalability, and statelessness are important. It's often a good choice for mobile applications and resource-based interactions.

• Use SOAP:

  • When you need a more formal contract, strong typing, and built-in security. It's suitable for enterprise-level applications where standards compliance and ACID transactions are crucial.

Ultimately, the decision depends on your specific project requirements, the ecosystem you are working in, and the trade-offs you are willing to make in terms of complexity, standards, and flexibility.

So between Mendix Apps it's absolutely fine to use OData - REST is only the Backup if you want to interact with the "outside Mendix world". And SOAP is only for historical reasons in Mendix?