This depends on level of coupling and clarity of abstraction between the GUI and web-service.
Following conditions at architectural level are must to make things work :
- The abstractions of data elements must be clearly well defined. Also, if the data exchange is closer to the schema of DB on the web service side, it would be easier. (if applicable).
- The flow of message exchanges must be very clearly articulated. the more stateless it is, the better it is.
- Web-service should have NO knowledge of the how the GUI is using the data, and there should be no specific logic in the implementation of webservice.
For example, depending on the current view or last query, web-service should not be doing computation.
- It is best that sessions of web front-end are kept away from service or restricted; mechanisms like authentication should either be based on independent brokers (like OpenID) or it is shielded between User to GUI vs. GUI to Web service.
- Business rules are well documented and agreed upon.
- Application of encryption of messages if applicable.
In general try to design web service API such that at least two different type of GUI might need to use it without having to run in inconsistent behavior. (this helps you to make conscious notice of GUI specific coupling).
The above are most basic rules for any to any platform. Apart from this, since you have mentioned, that this is a marriage between .NET and PHP, i would try to play safe and communicate only using pure XML. So i guess REST or even better plain old XML RPC might just work much better than SOAP. It is not that SOAP cannot work - but i guess it wont be without the trouble compared to "plain XML" communication.