REST is superior to SOAP in many respects, including the following:

• Developing a public API: REST, which is famous for ROA, invariably focuses on resource-based or data-based operations. Its core operations (GET, PUT, POST, and DELETE) are inherited from the ubiquitous HTTP. This minimalist approach makes the REST paradigm easy to understand and use across application and industry domains. Application and service developers find it easy to play around with the RESTful approach. The response gets easily consumed by web browsers. Precisely speaking, the simplicity innately provided by REST is one of the key reasons for its unprecedented support and success. Realizing its potential, there is a consistent transition from SOAP to REST. 
• Performance, flexibility, and scalability: APIs are the entry point for applications to be identified, integrated, and used. There are event messages and procedure/method calls between applications' APIs. A widely circulated tip is that applications that require a lot of back-and-forth messaging have to choose the REST way in order to be successful. If there's a networking issue, the RESTful service approach allows the application/process to retry once the connection is re-established. REST makes it easy to do so without any major interruption. With SOAP stateful operations, the retry aspect seems to be a difficult affair as it involves more initialization at multiple levels, including the state code. Since REST is stateless, the session information isn't stored on the server machine, and this enables REST services to be independently retried and horizontally scalable. 

The RESTful service paradigm enables us to perform easy and fast calls to a URL and get an immediate response. SOAP services require the keeping of a stateful connection with a complex client. REST, on the other hand, bats for stateless connection. The cache isn't stored in server applications. Therefore, testing RESTful applications is quite easy compared to SOAP applications. 

SOAP provides ways of remotely accessing and manipulating objects (nouns) through procedure/method requests; REST focuses on the operations (verbs) that can be executed on resources. REST, therefore, has been widely adopted by public API practitioners. REST is always better than SOAP in situations that don't mandate for the full map for a set of objects to the client. Transmitting object details back and forth will waste a lot of expensive network bandwidth. Also, network latency comes into the picture. Especially in bandwidth-starved environments, this multiple-call requirement can be a huge barrier. APIs consumed mostly by mobile applications relate to those scenarios where we don't need to leverage SOAP at all costs. Public APIs frequently change because the expectations of consumers and businesses vary. In this world of start-ups and APIs without specific contractual agreements, REST is a natural and universal choice.