That said, here his my opinion about shifting from SOAP to REST, from my experience.
At Lucca we are strong RESTafarians, and big fan of Zachman (a framework for enterprise architecture).
From what I understand of SOAP, the idea is to connect 2 systems together. So developpers of system A read the system B documentation (list of clases and methods) and decide to rely on this method or another one. When the method they want to call does not exist, they ask system A to add such a method.
In this scenario, I would say that the public endpoint that system A exposes throught SOAP is "client oriented", is made for easy consumption, respond to a formalized need.
Whereas, when you want to make a REST API, the situation would much more look like this :
- product people and developpers decide wich resources they want to handle in system A. For that, you can rely on Zachman, or apply DomainDrivenDesign principles. You have to find primitive resources that reflect you domain processes
- system A now exposes resources that does not correspond to any need, but that reflect best for them the way domain model can be exposed. For instance, if system A is a leave management system (that's what we work on at Lucca), the REST API exposes users, leaveAccounts, leaveRequest, entries and leaves (when you want to make a leaveRequest, the system would debit your entries and create leaves so that other users can see in a calendar that you are asbent.
- the front end of system A could have need that are not directly handled by the REST API, that why we often build a BFF (BackendForFrontend) that aggregates some resources for the need of the frontend.
- eventually, we get to system B that has needs as well, and we tell them to use system A API, but system A would merely change anything for system B to connect, because the REST API is not "client oriented", it is architecture oriented.
So for transitioning from SOAP to REST I would say that you first have to expose your domain through REST API, then keep the SOAP endpoints and connect them to one or multiple REST resources.
Clients can now still go throught the SOAP API or if the RESP API respond to their needs, switch to it.
Hope this help.
Retrouvez l'actualité des métiers administratifs et RH sur notre magazine
Associé, responsable R&D
13 rue Martin Bernard
75013 Paris - France
Standard : +33 (0)1 83 64 53 20