I have implemented a REST API before and I really liked it. In general when you implement REST over SOAP, your client/server is more orthogonal meaning that you can a lot more freely change the server without affecting your client(s). This orthogonality is due to using a more abstract and already well defined communication via HTTP verbs. Also, the use of hyperlinks embedded in your REST responses make it easier to extend and grow your API relatively pain free. Clients are supposed to follow these embedded links to get to new resources like a human would follow links on a webpage to 'drill down' for more information.

With that said, I had some coworkers who were told they had to use SOAP and they complained about it all the time. So I went into researching the two a bit more in detail.

In general what I found is that REST is well suited for highly distributed applications, when you have hundreds, thousands or millions of clients. One reason is the above mentioned orthogonality, another is caching that you get for free since you are using HTTP.

SOAP might be the quicker way to go when you need a smaller API for a client or two quickly and you are not too worried about scalability. It might also fit you better if you do not have an architecture that is structured around resources, because it might take you some time to restructure your app to even be able to implement REST.

Just by the question, one cannot pinpoint a single pattern because there are multiple aspects to a pattern. Depending on how your service is architected, the pattern can vary. In general, however, what you specified is the overarching Service Abstraction design principle.

Also, quite often a piece of software, especially at the scope of a web-service, is composed of multiple design patterns. Thus a web service may be designed with Model-View-Controller pattern while has a set of adapters, data mappers, (explained below) etc. in its various layers. You can still identify its primary business value and map that to a design pattern if that is important for your project. Thus, even though not all the patterns I talk about below may be considered enterprise design patterns by everyone, I find it more useful to use the pattern that conveys what the service does more than whether it is necessarily an enterprise design pattern or not.

From what you stated in your question, it seems most likely to be a Façade or its specialization Remote Façade. It would be a Façade if its primary purpose were to simplify the underlying API and hide the complexity (which is what you are stating). Remote Façade additionally also aims to reduce the number of calls between two systems if that's a concern.

An Adapter pattern is usually architected with an assumption that there are going to be multiple adapters (whether in present or in future). Thus, if your primary concern is to create a web service such that it would provide a consistent interface and be able to perform various operations on underlying service(s), then you are designing an adapter. A typical example would be when you are offering a new deployment service, and expose a method called Compile(). It implements two adapters, one for MSBuild and the other for nmake. Depending on which system a particular project is written in, it will pick up the correct adapter and issue appropriate commands.

A similar pattern is the Data Mapper which is mapping of a consistent set of data types to data types of various underlying data stores. Let's say if your service was exposing a UserId field to its client such that it mapped to a UserName and an UserPrincipal field in two different data stores, then this is what you are looking at. It does not mean that you necessarily have multiple data stores, it means that you are architecting with that possibility in mind.

The Bridge pattern is usually applied where there is an abstraction and its implementation, and yet both need to be varied. Typically, the implementation is achieved using an adapter pattern, so you end up with the Abstraction and its subclasses, as well as a set of adapters.

A Gateway is more around providing a consistent interface between services. So you could have a www.myservice.com which exposes a REST API, which in turn calls other services which may be using various protocols. It is the responsibility of the Gateway to ensure that clients always get the same interface, even when any of those services decides to change its protocols.