4 ms·

Server returning HTML responses? Yuck! How do you deal with that on mobile platforms such as iOS and Android? No, thank you! Plain old JSON is just fine.

carsongross 11y ago
I know: a server returning html. It will never work. EDIT: I've fallen into the ad internetum trap; I shouldn't be so flippant. Sorry about that. What I am saying is that, for JSON APIs that are needed (for, say, mobile clients) that REST is probably not a great architecture, and it will and should move towards something more like SQL: a single RPC URL with a very rich query and update syntax. Where REST can still deliver a tremendous amount of value is in pure HTML applications, and intercooler helps make that possible within the context of a modern web application.
- cdcarter 11y ago
  Indeed. Things like GraphQL and even OData should hopefully take over the vague idea of "JSON available at a resource" which is needlessly complicated for most APIs.
  - hvidgaard 11y ago
    I have great hope for OData, but I just wish the team would focus more on getting it to work with ASP.NET 5 - it's in RC1 already.... As it stands I've decided to not use it at work, simply because I have no idea of when or if it will be a first class citizen of the system.
  - mercer 11y ago
    I never liked the ('orthodox') RESTful approach when building web apps and I didn't understand why so many codebases I've worked with seemed to bend over backwards to be as RESTful as possible with (seemingly) no benefit. I feel like I now have a slightly better understanding of why I felt this way (and some more 'authoritative' support, I guess).
- gumballhead 11y ago
  Not that i love REST, but for an app that needs to work offline, boring ass REST is a pretty straight forward way to sync the mobile and remote databases.
- mercer 11y ago
  To be honest, your occasional comment promoting Intercooler.js became rather annoying to me, to the extent that I even thought about doing another 'HN Comments parody' just so I could feature you prominently (among others). But this comment somehow is the first time I have a better perspective on what it is exactly you're pushing, and whether it's my fault for dismissing you earlier or not, I just wanted to let you know that while I don't have a use for your tool right now, I feel like I get it and I even agree with your reasoning. Furthermore, I applaud anyone who build something and seems passionate about it, and I hate falling into the trap of being negative. My apologies thinking that way. (that said, if I were to do a comment parody, you'd be featured. just with a more friendly thought behind it.)
  - carsongross 11y ago
    (lol) Yeah, I recognize how quixotic and annoying I can be about the whole thing: I certainly deserve parody. I'm a lone developer up in Sacramento trying to compete for mindshare with Facebook and Google. It's ridiculous and extremely funny. Thanks for being fair-minded about it. :)
- paulddraper 11y ago
  Like GraphQL?
sampsonetics 11y ago
I was under the impression that iOS and Android both support HTML right out of the box. Do they no longer bundle Web browsers, or are you suggesting some other drawback that is critical to your particular application?
- deckar01 11y ago
  I assume they are using the same JSON API for their client side web app and their native mobile apps. Is there a compelling argument to move template rendering to the server if the native applications don't render using a HTML DOM?
- EvanPlaice 11y ago
  Not for mobile apps. An app can display html via a web view but that has already proven to be a terrible experience. There's a reason JSON APIs have become more popular. Besides, clear separation of data from view means the data can be used by other third-party services. The future of mobile apps will be native client-side view rendering from SPAs like React Native, Angular2 Universal. Not serving HTML views.
virmundi 11y ago
It all depends on your context. If you are making a website, HTML on the mobile. If you're making an API, you can use JSON, just don't call it REST. People seem to overlook RPC over HTTP. There is nothing wrong with that model. Look at the early RPC implementations. They look like objects with a set of wlverbs. A URI can be treated logically as an object. /users is an object. Implicit ops are the HTTP verbs. How you move between objects is probably API specific. If you are using JSON, it is API specific because JSON currently lacks linking capacity.
virmundi 11y ago
It all depends on your context. If you are making a website, HTML on the mobile. If you're making an API, you can use JSON, just don't call it REST. People seem to overlook RPC over HTTP. There is nothing wrong with that model. Look at the early RPC implementations. They look like objects with a set of wlverbs. A URI can be treated logically as an object. /users is an object. Implicit ops are the HTTP verbs. How you move between objects is probably API specific. If you are using JSON, it is API specific because JSON currently lacks linking capacity.

carsongross 11y ago

I know: a server returning html. It will never work. EDIT: I've fallen into the ad internetum trap; I shouldn't be so flippant. Sorry about that. What I am saying is that, for JSON APIs that are needed (for, say, mobile clients) that REST is probably not a great architecture, and it will and should move towards something more like SQL: a single RPC URL with a very rich query and update syntax. Where REST can still deliver a tremendous amount of value is in pure HTML applications, and intercooler helps make that possible within the context of a modern web application.

cdcarter 11y ago
Indeed. Things like GraphQL and even OData should hopefully take over the vague idea of "JSON available at a resource" which is needlessly complicated for most APIs.
- hvidgaard 11y ago
  I have great hope for OData, but I just wish the team would focus more on getting it to work with ASP.NET 5 - it's in RC1 already.... As it stands I've decided to not use it at work, simply because I have no idea of when or if it will be a first class citizen of the system.
- mercer 11y ago
  I never liked the ('orthodox') RESTful approach when building web apps and I didn't understand why so many codebases I've worked with seemed to bend over backwards to be as RESTful as possible with (seemingly) no benefit. I feel like I now have a slightly better understanding of why I felt this way (and some more 'authoritative' support, I guess).
gumballhead 11y ago
Not that i love REST, but for an app that needs to work offline, boring ass REST is a pretty straight forward way to sync the mobile and remote databases.
mercer 11y ago
To be honest, your occasional comment promoting Intercooler.js became rather annoying to me, to the extent that I even thought about doing another 'HN Comments parody' just so I could feature you prominently (among others). But this comment somehow is the first time I have a better perspective on what it is exactly you're pushing, and whether it's my fault for dismissing you earlier or not, I just wanted to let you know that while I don't have a use for your tool right now, I feel like I get it and I even agree with your reasoning. Furthermore, I applaud anyone who build something and seems passionate about it, and I hate falling into the trap of being negative. My apologies thinking that way. (that said, if I were to do a comment parody, you'd be featured. just with a more friendly thought behind it.)
- carsongross 11y ago
  (lol) Yeah, I recognize how quixotic and annoying I can be about the whole thing: I certainly deserve parody. I'm a lone developer up in Sacramento trying to compete for mindshare with Facebook and Google. It's ridiculous and extremely funny. Thanks for being fair-minded about it. :)
paulddraper 11y ago
Like GraphQL?

sampsonetics 11y ago

I was under the impression that iOS and Android both support HTML right out of the box. Do they no longer bundle Web browsers, or are you suggesting some other drawback that is critical to your particular application?

deckar01 11y ago
I assume they are using the same JSON API for their client side web app and their native mobile apps. Is there a compelling argument to move template rendering to the server if the native applications don't render using a HTML DOM?
EvanPlaice 11y ago
Not for mobile apps. An app can display html via a web view but that has already proven to be a terrible experience. There's a reason JSON APIs have become more popular. Besides, clear separation of data from view means the data can be used by other third-party services. The future of mobile apps will be native client-side view rendering from SPAs like React Native, Angular2 Universal. Not serving HTML views.

virmundi 11y ago

It all depends on your context. If you are making a website, HTML on the mobile. If you're making an API, you can use JSON, just don't call it REST. People seem to overlook RPC over HTTP. There is nothing wrong with that model. Look at the early RPC implementations. They look like objects with a set of wlverbs. A URI can be treated logically as an object. /users is an object. Implicit ops are the HTTP verbs. How you move between objects is probably API specific. If you are using JSON, it is API specific because JSON currently lacks linking capacity.

virmundi 11y ago