Home/ Questions/Q 3220440
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T15:45:42+00:00

My next project involves the creation of a data API within an enterprise framework.

  • 0

My next project involves the creation of a data API within an enterprise framework. The data will be consumed by several applications running on different software platforms. While my colleagues generally favour SOAP, I would like to use a RESTful architecture.

Most of the applications will only need a few objects at every call. Other applications will however sometimes need to make several sequential calls each involving thousands of records. I’m concerned about performance. Serialization/deserialization & network usage are where I fear to find a bottleneck. If each request involves a large delay, all of the enterprise’s applications will be sluggish.

Are my fears realistic? Will serialization to a voluminous format like XML or JSON be a problem? Are there alternatives?

In the past, we’ve had to do these large data transfers using a “flatter”/leaner file format such as CSV for performance. How can I hope to achieve the performance I need using a web service?

While I’d prefer replies specific to REST, I’m interested in hearing how SOAP users might deal with this as well.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    We offer both XML and JSON. Your mentioned rendering time really can be an issue. On server side we have JAXB whose standard sun-implementation is somewhat slow, when it comes to marshall XML. XML has the disadvantage of verbosity, but is also nice in interoperability and has schema + explicit versioning.

    We compensated the verbosity in several ways (especially limiting the result-set):

    • In case you have a container with items in it, offer paging in your xml response (both page-size and page-number, e.g. /items?page=0&size=3) . The client can itself reduce the size by reducing the page-size.
    • Offer collapsing elements, for instance several clients are only interested in one data field of your whole item. Do this with a parameter (e.g. /items?select=name), then only the nested element ‘name’ is included inline of your item element. This dramatically decreases size.

    Generally give the clients the power to use result-set limiting. They will definitley use it, because it speeds up response time also on their side 🙂

    Also use compression, it reduces verbose XML extremely (in our case the payload got 10 times smaller). From client side you can do it by header ‘Accept-Encoding: gzip’. If you use Apache, server configuration is also straight-forward

    • 0