5 ms·

> This is what we call "screen-scraping", and it's a pretty tough road to consume an API like that. That's hyperbole. If you're willing to accept clients which

> This is what we call "screen-scraping", and it's a pretty tough road to consume an API like that. That's hyperbole. If you're willing to accept clients which are hard-coded to some specific JSON structure, then we can accept clients which are hard-coded to some specific HTML structure. The point is that a HATEOAS API will, by default and with no extra work from anyone, be browsable via any Web browser (including those with assistive tech like screen readers, etc.). In contrast, the best we have for JSON APIs is to pretty-print the response text, perhaps with syntax highlighting; embedded URLs might be made clickable, but we're probably restricted to only performing GETs. If we use HATEOAS this might actually be enough for our purposes; e.g. if we just want to expose some basic functionality, like an admin UI. If not, we can write a client for that API; again, this doesn't require screen-scraping, or solving ambiguous parse issues, etc. since the client is not a general Web browser. If we use JSON, we are pretty much forced to build a bespoke client for the API; due to how little we get 'by default'.

javajosh 5y ago
> [Comparing HAS consumption to screen-scraping] That's hyperbole. How does it differ, then? Do you have any code examples? Based on your next statement: If you're willing to accept clients which are hard-coded to some specific JSON structure, then we can accept clients which are hard-coded to some specific HTML structure it does not differ, but you instead say that both approaches require hard-coded clients to consume programmatically, so they are equivalent. If that were so, then another approach like embedding results in a jpg, would be equally valid since you just have to hard-code your clients to extract information from the jpg. After all the human can parse this so we don't need a bespoke client. From the perspective of theoretical movement of data from a to b, yes of course this is true. But from the perspective of an engineer consuming it, no, they are very different. And the difference is that entropy is proportional to developer pain. I hope you try to be more rational and less ideological about your ideas. I'll leave it at that. I really like thinking about alternative architectures, but this one's appeal seems to rely on ignoring some very real trade-offs.
- chriswarbo 5y ago
  > Do you have any code examples? For extracting known elements from HTML that's under our control? That's a pretty standard task; here's a shell command to extract the 'deposits' URL from the article's example code: xidel -q -e '//a/@href' - | grep '/deposits' How on Earth is that equivalent to OCRing a JPEG? > I hope you try to be more rational and less ideological about your ideas. What's "ideological" about claiming that it's easy to parse known elements from (X)HTML that we control?

javajosh 5y ago

> [Comparing HAS consumption to screen-scraping] That's hyperbole. How does it differ, then? Do you have any code examples? Based on your next statement: If you're willing to accept clients which are hard-coded to some specific JSON structure, then we can accept clients which are hard-coded to some specific HTML structure it does not differ, but you instead say that both approaches require hard-coded clients to consume programmatically, so they are equivalent. If that were so, then another approach like embedding results in a jpg, would be equally valid since you just have to hard-code your clients to extract information from the jpg. After all the human can parse this so we don't need a bespoke client. From the perspective of theoretical movement of data from a to b, yes of course this is true. But from the perspective of an engineer consuming it, no, they are very different. And the difference is that entropy is proportional to developer pain. I hope you try to be more rational and less ideological about your ideas. I'll leave it at that. I really like thinking about alternative architectures, but this one's appeal seems to rely on ignoring some very real trade-offs.

chriswarbo 5y ago
> Do you have any code examples? For extracting known elements from HTML that's under our control? That's a pretty standard task; here's a shell command to extract the 'deposits' URL from the article's example code: xidel -q -e '//a/@href' - | grep '/deposits' How on Earth is that equivalent to OCRing a JPEG? > I hope you try to be more rational and less ideological about your ideas. What's "ideological" about claiming that it's easy to parse known elements from (X)HTML that we control?