1) The RESTful web service may not be consumed by JavaScript code. Most likely, it will be consumed by other languages like Java, PHP, ASP .Net etc.
2) The size of data is not only concern for the system. Encoding and decoding performance should be considered too.
3) XML parser has been developed and improved for years. JSON parse engine newer than XML.
4) I saw Zend Framework JSON encode and decode functions are pure PHP code. It's performance needs to be investigated.
5) More importantly, one of reasons for me to chose RESTful is that the service going to be implemented is more about sharing resource than about exposing RPC functions. Concept about Resource need to be always with people who design and implements RESTful Web Service. When we talk about resource, we should not forget that the Internet is invented to share resource among people. Furthermore, hyperlink is invented to be key feature of the Internet. Hyperlink feature makes the Internet to be called as Web though HTTP protocol is not the only thing used to transfer data over the Internet.
We have hypertext, hypermedia etc. Now, we have RESTful Web service. Will we have something like hyper-RESTful? Obviously, the answer will be YES. In fact, this should be one of major reasons for us to use XML as output format as we have XLink in XML already. Below is one sample output of RESTful Web service in XML format.
As we can see, this output is not a simple one "page" of XML document. It contains hyperlinks to other resources, which could be another RESTful Web service. With this in mind, RESTful designer can borrow methodology of creating Web site to design and "expanding" their RESTful service. That is, we do not need to develop a dedicated service, which will do every thing by itself and it wont share resource with other service. One RESTful web service could be implemented as a piece of "page". Then, another RESTful web service can be composed by using multiple RESTful web service. This architecture will give RESTful Web service more flexibility in terms of deployment and network optimizing.CUSTOMER INVOICE ITEM PRODUCT
Won't we lost this great hyperlink feature, which is nature for the Internet if we use JSON? I think 1) JSON may not give whole system better performance if we consider not only data size but also encoding/decoding speed and memory usage. 2) XML will give us great feature of hyplelink from the Web. XLink is just the technique from XML world.
Below is a picture linked from a blog post Native JSON Support is Required.
It is an article written and experiment made in 2007. Now, the things has been different as modern browsers have native JSON support already. However, it is still helpful to remind people who know JSON has more compact size than XML and missed other important factors in the system.
JSON or XML? I think there are different answers for different software system. However, it is thoughtless to assert JSON is better than XML just because of the uncompressed data size. Back to the topic, I will say it is good to use XML as output format of RESTful when the service is not consumed by JavaScript running in Web browser. Of course, it won't be difficult to make RESTful service to be configurable to output XML or JSON.
No comments:
Post a Comment