Author: Jordan Mack 2011-12-19 18:13:08
Published on: 2011-12-19T18:13:08+00:00
The debate on using HTTP for data interchange is ongoing, with some opting for an HTTP multipart response to achieve the need for multiple named resources. However, it is argued that parsing a multipart response is not simple, and library support is weak across many languages. Additionally, the widely adopted cURL library does not support multipart response parsing at all. On the other hand, JSON is widely adopted, human readable, and has parsing libraries available for every major language. Despite some additional bloat, it is considered convenient and easy to use for developers. If the aim is to "keep it simple and straightforward" (KISS) and provide a quick and easy-to-implement method for developers, then JSON is a standout option. Using HTTP for data interchange may make things difficult for several developers if multipart responses are used. Therefore, JSON is preferred as it is greeted with open arms. However, some argue that HTTP has everything necessary and bloating the payload with json/xml is unnecessary. They also note that the argument of having JSON in the client already is wrong since JSON in server RPC solves another problem (and solves it wrong due to data type issues).
Updated on: 2023-06-04T21:58:12.324420+00:00