Your question about SOAP and REST in deployment diagram has two parts: the services and the communication protocol:
- the services expose an API and process incoming request. In your diagram, this is represented with respective API components on the web server, which seem to expose the API to the outside words, and dispatch the requests to backend execution environments.
- the communication protocol, which use an http communication path from outside world to the web server, and use dedicated SOAP over http and REST over http with the backend execution environments.
This seems perfectly fine, if this is what you're doing. The only question that I'd have, is whether you'd have some client-side code, in which case, the browser should be an execution environment, and the JavaScript would materialise components executing inside the browser.
The dashed dependency arrows that you seem to use to clarify between which components the communication takes place, are however ambiguous, because nothing in the UML specs relate this dependency to the communication.
A less ambiguous way would be to use sockets and lollipops on the components, and have the dependencies between these elements. If in the web server side, you don't really have different API components but the web controller is dispatching to the backend, you could replace them by sockets and use a «REST»
and «SOAP»
stereotype and draw the interface dependency to the interfaces provided by the backends.