3 ms·

When you're working with sockets there's lots to think about that you can simply ignore with an HTTP library -- connection setup and teardown, buffering, serial

When you're working with sockets there's lots to think about that you can simply ignore with an HTTP library -- connection setup and teardown, buffering, serialization, byte ordering etc. But more importantly, you'll have to build your own status/error handling, cache control, content encoding, TLS etc. (Simply, doing TLS correctly itself is not easy.) To be clear, I'm not saying that there's no place for socket programming -- there definitely is. I've spent a good part of my life doing obscure network programming on all kinds of platforms, so I try not to use TCP/UDP unless I have a really good reason. (It's kinda the same reason I won't use C or C++ -- too much to worry about for most general purposes.)

jolmg 7y ago
Thanks for the reply. This gives me a better understanding of the issue here. > connection setup and teardown If there's no benefit in avoiding setting up and tearing down a connection with each request like one typically does with HTTP, then I can see how it might be an annoyance compared to making a single function call from a library that makes the request and returns the response. > buffering A parser should deal with that. It could be JSON parser. > serialization That's still a problem with HTTP. People typically use JSON for this and it doesn't depend on HTTP. > byte ordering parser/JSON's job. > your own status/error handling, cache control, content encoding That can be beneficial or it can be problematic. If you need such things, then yeah, it's cool to not have to think about making your own. However, if you don't or if your needs don't align with what HTTP provides, that can be problematic. For example, from a cursory search I see the following in the JMAP spec: > Implementors must take care to avoid inappropriate caching of the session object at the HTTP layer. Since the client should only refetch when it detects there is a change (via the sessionState property of an API response), it is RECOMMENDED to disable HTTP caching altogether, for example by setting `Cache-Control: no-cache, no-store, must-revalidate` on the response. So, HTTP provides caching, but not the caching mechanism that's needed, so it's recommended to explicitly disable it completely. With respect to status and error handling, it seems JMAP still had to define their own errors to be described in JSON[1], so not a perfect fit there either. On the content encoding, I'm not sure if JMAP would use something other than application/json, so it seems like something that wouldn't need to be specified if one didn't use HTTP. I know the discussion is not really about JMAP. I'm just using JMAP as an example on the above. > TLS etc. (Simply, doing TLS correctly itself is not easy.) I would hope that there's a library equivalent of the shell's: openssl s_client -connect $host:$port I don't know why a library would have to be much more complicated. Maybe I'm being naive, but I think that if one wouldn't specify special TLS parameters to an HTTP library, then there's no reason why one would need to if they skip the HTTP library and go straight to using a TLS library. IOW, I don't see why an HTTP library would be more helpful on setting up TLS than using a TLS library directly. [1] https://jmap.io/spec-core.html#initial-jmap-error-codes-registry https://jmap.io/spec-core.html#initial-jmap-error-codes-regi...

jolmg 7y ago

Thanks for the reply. This gives me a better understanding of the issue here. > connection setup and teardown If there's no benefit in avoiding setting up and tearing down a connection with each request like one typically does with HTTP, then I can see how it might be an annoyance compared to making a single function call from a library that makes the request and returns the response. > buffering A parser should deal with that. It could be JSON parser. > serialization That's still a problem with HTTP. People typically use JSON for this and it doesn't depend on HTTP. > byte ordering parser/JSON's job. > your own status/error handling, cache control, content encoding That can be beneficial or it can be problematic. If you need such things, then yeah, it's cool to not have to think about making your own. However, if you don't or if your needs don't align with what HTTP provides, that can be problematic. For example, from a cursory search I see the following in the JMAP spec: > Implementors must take care to avoid inappropriate caching of the session object at the HTTP layer. Since the client should only refetch when it detects there is a change (via the sessionState property of an API response), it is RECOMMENDED to disable HTTP caching altogether, for example by setting `Cache-Control: no-cache, no-store, must-revalidate` on the response. So, HTTP provides caching, but not the caching mechanism that's needed, so it's recommended to explicitly disable it completely. With respect to status and error handling, it seems JMAP still had to define their own errors to be described in JSON[1], so not a perfect fit there either. On the content encoding, I'm not sure if JMAP would use something other than application/json, so it seems like something that wouldn't need to be specified if one didn't use HTTP. I know the discussion is not really about JMAP. I'm just using JMAP as an example on the above. > TLS etc. (Simply, doing TLS correctly itself is not easy.) I would hope that there's a library equivalent of the shell's: openssl s_client -connect $host:$port I don't know why a library would have to be much more complicated. Maybe I'm being naive, but I think that if one wouldn't specify special TLS parameters to an HTTP library, then there's no reason why one would need to if they skip the HTTP library and go straight to using a TLS library. IOW, I don't see why an HTTP library would be more helpful on setting up TLS than using a TLS library directly. [1] https://jmap.io/spec-core.html#initial-jmap-error-codes-registry https://jmap.io/spec-core.html#initial-jmap-error-codes-regi...