I am creating a software for B2B which targets all kinds of large size companies. It will integrate with existing softwares of companies (CRM and ERP systems). I want to expose my API via REST. However, I wonder that do I need to SOAP web services too since it may not be used by companies?

I mean how is the ecosystem right now if you tell your customers you cannot interact with my system via SOAP?

  • By XML, do you mean SOAP? – TZHX Oct 8 '16 at 18:37
  • Yes, I mean SOAP. – kamaci Oct 8 '16 at 19:06
  • When you say "since it may not be used by companies", do you mean "since there may be some companies which do not use REST APIs"? – Tanner Swett Oct 9 '16 at 4:56
  • If the system you want to integrate with can be configured by the user to call in to SOAP (but not REST) API's by the user, without the need of support from the providers of those CRM/ERP systems, then you probably want to enable that, yes. It seems more likely, though, that the integration will be you calling into their APIs. So really... it's up to you. I don't think you'll find a company that point blank refuses to use REST-ful APIs. – TZHX Oct 9 '16 at 8:20
  • Long story short, you need to provide SOAP APIs if that's what your customer require for your solution to meet their needs. That's really not something we can help you with (though I would suggest trying to use the correct words for things, to avoid confusion. REST services can be configured to return XML as well as JSON so saying to someone "do you need XML APIs" doesn't ask them what you actually want to ask). – TZHX Oct 9 '16 at 8:21

If you should provide an API for other existent products to interact with, then your choice should be based on the requirements of those products. Comments by TZHX explain all that in detail.

I suppose, however, that it's not your situation. In other words, CRM and ERP systems don't interact with your software: instead, your product interacts with those CRM and ERP systems through the API they expose. Your intention is to simply have an API for future products which could be built around your product, and your question is about that API.

In this case, the answer is rather straightforward. Basically, SOAP's popularity is decreasing, while REST appears very attractive. Aside the REST hype, there are concrete reasons which explain that: SOAP is more bandwidth heavy, especially compared to JSON-based REST, and SOAP has its niche, which is narrowing over time. For instance, in Microsoft's world, SOAP through WCF is an interesting option; however, WCF's future is rather unfortunate.

Providing SOAP may make sense in some situations:

  • Your product is in a field where everyone uses SOAP on daily basis. If all your competitors provide a SOAP API, you may have one as well.

  • Your product is addressed to the developers who used SOAP in the past and don't know or care about REST.

  • The developers who will interact with your product have some powerful tools which make it easy to use SOAP. For instance, in WCF projects, any service which presents itself through WSDL can be imported in Visual Studio, and its client source code will be generated, automatically. And updated automatically as well when the service changes. Very convenient.

In other cases, REST API is largely enough. Note that you can develop both the API and the API clients in mainstream languages, making it easier for other developers to interact with your API. For instance, Amazon does that, and so do Google and Twilio and others.

Note that technologies and ecosystems matter a lot. For instance, consuming a SOAP service from JavaScript won't be particularly straightforward. On the other hand, if you want to provide a .NET service consumed from a .NET application, SOAP provides the fastest alternative, most code being generated for you.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.