š
Original date posted:2011-12-19
šļø Summary of this message: HTTP multipart response is not simple to parse and lacks library support. JSON is widely adopted, human-readable, and has parsing libraries available for every major language. Using HTTP for data interchange will make things difficult for developers.
š Original message:With all due respect, I continue to disagree on the topic of using HTTP
for data interchange.
Yes, an HTTP multipart response will accomplish the need for multiple
named resources. The problem is that parsing of a multipart response
isn't simple, and library support is weak across many languages. The
widely adopted cURL library does not support multipart response parsing
at all.
JSON is widely adopted, human readable, and has parsing libraries
available for every major language. There is a bit of additional bloat,
but I believe it is warranted in this case because of the convenience
and ease it brings to developers.
If the idea is to "KISS", and provide a method that is both quick and
easy to implement for the average developer, then JSON is a stand out
option. Using HTTP for the data interchange will make things difficult
for a lot of developers if multipart responses are used. JSON will be
greeted with open arms.
On 12/19/2011 9:09 AM, slush wrote:
> I agree with Luke that HTTP standard has everything necessary and
> bloating payload with json/xml is not necessary.
>
> Btw that argument "we have json in client already" seems pretty wrong,
> because json in server rpc solves another problem (and solve it in wrong
> way, because of data type issues, but it's another story).
Jordan Mack [ARCHIVE] /
npub18yā¦3txp2
2023-06-07 02:44:45
in reply to nevent1qā¦5s4y
Author Public Key
npub18yq2ukhtlnkuzzykluyjvxap3vtvdqf0arvtag6rx02klk6gymgqp3txp2Published at
2023-06-07 02:44:45Event JSON
{
"id": "4aaedb59f80864504bbd2b0d35557afbcde22498fd5535bd7bd5bdbb306a4547",
"pubkey": "3900ae5aebfcedc10896ff09261ba18b16c6812fe8d8bea34333d56fdb4826d0",
"created_at": 1686105885,
"kind": 1,
"tags": [
[
"e",
"247922e9146ee6b54a634fc05ad7a489892c01debcd0510d008be95a47f6db80",
"",
"root"
],
[
"e",
"ee4ea8751bdbafa73c118d5c97ffcd83889e7ddf5686b74ba8c64589c69de330",
"",
"reply"
],
[
"p",
"eb7ca795057ca7cabde6f541c741e661d013414934e5934c2e04c6677625c99a"
]
],
"content": "š
Original date posted:2011-12-19\nšļø Summary of this message: HTTP multipart response is not simple to parse and lacks library support. JSON is widely adopted, human-readable, and has parsing libraries available for every major language. Using HTTP for data interchange will make things difficult for developers.\nš Original message:With all due respect, I continue to disagree on the topic of using HTTP \nfor data interchange.\n\nYes, an HTTP multipart response will accomplish the need for multiple \nnamed resources. The problem is that parsing of a multipart response \nisn't simple, and library support is weak across many languages. The \nwidely adopted cURL library does not support multipart response parsing \nat all.\n\nJSON is widely adopted, human readable, and has parsing libraries \navailable for every major language. There is a bit of additional bloat, \nbut I believe it is warranted in this case because of the convenience \nand ease it brings to developers.\n\nIf the idea is to \"KISS\", and provide a method that is both quick and \neasy to implement for the average developer, then JSON is a stand out \noption. Using HTTP for the data interchange will make things difficult \nfor a lot of developers if multipart responses are used. JSON will be \ngreeted with open arms.\n\n\n\nOn 12/19/2011 9:09 AM, slush wrote:\n\u003e I agree with Luke that HTTP standard has everything necessary and\n\u003e bloating payload with json/xml is not necessary.\n\u003e\n\u003e Btw that argument \"we have json in client already\" seems pretty wrong,\n\u003e because json in server rpc solves another problem (and solve it in wrong\n\u003e way, because of data type issues, but it's another story).",
"sig": "40d5a19d9ec3ecf6d9e8a2cdf6053d8f8ee96a8075eb8ce8f905a08111c8d8599b39c395ec9c0ed1b0791f1638d41d97f2a0558ddcdf2a1e4ff2867fef7bbdb7"
}