Practicality of URLs

When we communicate over sockets, we don't know what type of data format we are dealing with. This may be an issue in a client-server environment where clients are not aware of the kind of data server that would be broadcasted. In this case, either both the parties should be in agreement about the kind of data that will be used for communication, or we should establish our own way of communicating metadata along with primary data that will tell the data type of primary data.

Using Java's classes for HTTP support makes it possible to serve and access data objects with ease in regard to knowing their type and format. To make a document available on a URL, we can deploy the document on the web server along with the respective MIMEType configuration. URLConnection is used to request the URL from any specific client. However, there are issues with this method, which we will discuss next.

First, it adds a lot of overhead to the data stream that leads to bandwidth reduction between communicating systems. The second issue is that the entire data should be serializable to send it over HTTP. The third issue is with respect to the resource naming that HTTP is going to provide, as LDAP and NIS follow the formal naming procedure.

Therefore, we can conclude that for distributed applications where bandwidth is severely limited or where support for complicated resource hierarchies is required, the use of an HTTP protocol is not recommended. Whereas, if you have some extra bandwidth for communication and the performance requirements are not that critical and are relatively simple resource groupings, then the data can be accessed using URLs.