This is not as simple as it seems at first sight: both - rest and soap are ways to abstract apis. But(!) while rest follows a common schema, soap has no restrictions at all. In rest you take resources and offer always the same services for it. Let's say you have a user, then you offer
get NEW user data
CREATE a new user in the backend
UPDATE an existing user
SHOW an existing user
get all users at once from the INDEX
DELETE an existing user
The names of the methods are a convention and every rest api is build around this scheme.
A soap service has none of this conventions, so you could (and will) find all kind of functions and function-arguments. And this functions are not necessarily arranged around a single resource.
What I want to say is that it is not a question of mapping function names and arguments from xml to json - it is much, much more and even for small services very complicated and almost unmaintainable. If you decide for one of this approaches, stick with it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is not as simple as it seems at first sight: both - rest and soap are ways to abstract apis. But(!) while rest follows a common schema, soap has no restrictions at all. In rest you take resources and offer always the same services for it. Let's say you have a user, then you offer
The names of the methods are a convention and every rest api is build around this scheme.
A soap service has none of this conventions, so you could (and will) find all kind of functions and function-arguments. And this functions are not necessarily arranged around a single resource.
What I want to say is that it is not a question of mapping function names and arguments from xml to json - it is much, much more and even for small services very complicated and almost unmaintainable. If you decide for one of this approaches, stick with it.