Research on API development for server communication

1. SOAP

SOAP services, also known as Web Services, base their communication on SOAP. It is a standard protocol that defines how two objects in different processes can communicate by exchanging XML data.

Communication therefore happens through XML. These services usually run over HTTP, although they can also rely on other transport protocols such as FTP.

SOAP is commonly used in server-to-server or partner-to-partner scenarios because it is a more robust protocol and can include metadata and namespaces directly in the XML.

That is also why SOAP is heavier, both in payload size and in processing. XML documents must be parsed, namespaces resolved and content validated before they can be processed.

XML also provides strong validation mechanisms. JSON can be validated too, but its traditional ecosystem has usually been lighter and less rigid.

2. REST

REST is a flexible style that transports data through the different methods provided by HTTP, such as:

• GET: read a resource.
• POST: send data to create a resource.
• PUT: edit an existing resource.
• DELETE: delete a resource.
• PATCH: partially modify a resource.

REST also benefits from the standard response codes of HTTP itself, such as:

• 200 OK: accepted request and successful response.
• 201 CREATED: resource created successfully.
• 204 NO CONTENT: accepted request, with no data to return.
• 400 BAD REQUEST: invalid request.
• 401 UNAUTHORIZED: missing authorization.
• 403 FORBIDDEN: access to the resource is forbidden.
• 404 NOT FOUND: resource does not exist.
• 406 NOT ACCEPTABLE: requested format is not supported.
• 409 CONFLICT: conflict in the requested operation.
• 415 UNSUPPORTED MEDIA TYPE: unsupported content type.
• 500 INTERNAL SERVER ERROR: internal server error.

In REST, the client starts the request in order to obtain or modify a resource. Client and server exchange information using a format defined by the Content-Type header, which may be XML, JSON, binary or plain text.

Unlike SOAP, which focuses exclusively on XML, REST is frequently used with JSON, especially because JavaScript can consume it natively. This made it a natural fit for frameworks such as Angular or React.

The important point is that the client does not receive HTML to render, but only the response data. The server does not build the interface; it delivers the data so the frontend can process it.

Another relevant point is its independence from backend or database technology. The server can be implemented in PHP, Java, Python or Node.js; what matters is exposing the information in a suitable exchange format, usually JSON.

3. Conclusion

Thanks to the previous analysis, we can distinguish both solutions and choose the best option for a modern web application.

SOAP offers a robust, mature and structured solution based on XML and strong validation. However, it also brings several drawbacks:

• Greater implementation and processing complexity.
• Worse adaptation to mobile devices and rich web applications.
• Higher bandwidth consumption.
• Less use of the web native infrastructure.
• More friction with intermediate elements such as caches or firewalls.

For this reason, SOAP would not be the most suitable option for this project, because the application needs a lighter and more adaptable solution.

From the backend point of view, we need to provide the frontend with an easy way to obtain the data required by different user interfaces, such as Android, iOS or a web UI built with Angular or React.

In this context, the best solution is to implement a consistent REST API, capable of feeding different interfaces and also acting as a service source for third parties.

In short, REST can be understood as an interface between systems that uses HTTP to retrieve data or perform operations in formats such as XML or JSON. Compared with SOAP, it is usually the simpler and more suitable alternative for most current web applications.