3 ms·
https://jmap.io/#why-use-https/json https://jmap.io/#why-use-https/json?
by icebraining 8y ago
https://jmap.io/#why-use-https/json https://jmap.io/#why-use-https/json?
- jolmg 8y agoEverything mentioned there is because of its ubiquity, nothing about how the way HTTP operates makes it more suitable. What you link even says: > the encoding/transport part of JMAP [i.e. HTTP] is not core to its operation, so future specifications could easily add alternatives So HTTP is useless for this except for the fact that everyone uses it.
- detaro 8y ago"possible to replace with alternatives" != "useless"
- jolmg 8y agoBy useless I meant that the use of HTTP doesn't contribute anything essential. Though maybe I could be wrong? But that's what I understood by "is not core to its operation". I understand it to just wrap the JSON in HTTP for the benefits that come from its ubiquity in use and not so much because of merits of the mechanisms described in the HTTP spec.
- detaro 8y agoNo, it's just the most widely supported protocol of that kind, so why not use it? Is there anything specific against it/how do you answer for another protocol the question of "why not HTTP, which is similar and has better support?"? (Caveat: I think you'd ideally want http/2, which isn't as widely supported) EDIT: actually, one point: you can talk JMAP over HTTP(S) directly from a browser without a translating server.
- Arnt 8y agoThat's right. That was one of the first ~five sentences that were spoken about JMAP. Ubiquiti is a feature. Not having to explain the caching model to people is a feature.
- afiori 8y agoWhich can be read also as: HTTP allows to embed arbitrary semantics with close to no friction. Which sounds like a really good point together with the tooling and ubiquity