5 ms·

> "If it doesn't load through curl, it's broken." --someone So, so true. Thanks, curl.

by xrstf 12y ago

arethuza 12y ago
That's pretty much my own test for a Web based API - if I can drive it from the command line using curl then great, if I can't then it's broken.
laurent123456 12y ago
Curl is great and all but I don't think this quote makes much sense. Are there examples of services that would, for example, load in a browser but not through curl? I'd think it's rather the opposite since you can through pretty much anything at curl and it will work.
- cmg 12y ago
  Anything that requires JavaScript to fetch and display content.
  - VMG 12y ago
    Well somebody tell Google and Facebook, they're probably missing out on a lot of revenue because of their broken websites.
    - Piskvorrr 12y ago
      Broken != unprofitable.
    - Millennium 12y ago
      Website != API. A cleverly-written API can exist in the same space as a Website (even the same URLs, if you differentiate by things like Accept: headers), but they're not the same thing. It's perfectly acceptable for Websites to include, and even require the use of, JavaScript. It's also perfectly acceptable to offer a JavaScript client for your API. In fact, you pretty much have to do that if you want your Website to work with the API anyway. What's not OK is for an API to require downloading and using additional JavaScript while the API is being used. As a contrived (and somewhat ludicrous) example, let's say that I queried "http://foo.com/bars" http://foo.com/bars" for some kind of collection. It's OK to return the collection. It's even OK to use an HTTP redirect if the collection actually resides elsewhere: HTTP 302, perhaps, with a Location of "http://foo.com.bazes" http://foo.com.bazes". What's not OK is to return a line of JavaScript reading "window.location = 'http://foo.com/bazes';" http://foo.com/bazes';" which might work for the browser, but wouldn't work for most other clients.
  - twerquie 12y ago
    Yeah, building web apps this way is a fad. I predict everyone will go back to full page reloads and server-rendered content. /s
    - acdha 12y ago
      On a serious note, “progressive enhancement – still the right way”. I don't think client-side rendering is going away but everyone who's relied on it exclusively has learned the hard way that it's just too unreliable and slow to have a failure mode which is an empty page unless a lot of complex code works perfectly. Just think about how many engineer-hours Twitter flushed with that silly #! kludge – and then when they switched back, saw an 80% improvement in page load time.
      - ceejayoz 12y ago
        > Just think about how many engineer-hours Twitter flushed with that silly #! kludge – and then when they switched back, saw an 80% improvement in page load time. No hours were wasted, and they didn't really switch back. They're just using HTML5's History API on browsers that support it now. Essentially the same mechanism under the hood, just prettier URLs for it.
        hartator 12y ago
        I think he was making reference to the DOM rendering in the twitter website which used to be on client side until recently when they have switched back to server side rendering. But, it's very similar to pre-rendering React components on the server then mounting it so it might not be a total waste, that was a fad that didn't make a lot of sense for the time though.
        acdha 12y ago
        They did more than just switch to the history API. During that period, if anything went wrong, you saw a blank page and, of course, robots saw only the generic launcher HTML instead of any content. Now, here's what a tweet looks like without JavaScript enabled: https://www.dropbox.com/s/me7kinvje7ly781/Screenshot%202015-03-20%2019.42.30.png?dl=0 https://www.dropbox.com/s/me7kinvje7ly781/Screenshot%202015-... Here's what it looks with JavaScript enabled: https://www.dropbox.com/s/04pjdlkuht6t2ja/Screenshot%202015-03-20%2019.42.38.png?dl=0 https://www.dropbox.com/s/04pjdlkuht6t2ja/Screenshot%202015-... (The main difference would be that things like the search & menus are either interactive controls or simple links to basic HTML forms depending whether JavaScript loads) During the hashbang era you couldn't use a page without a full rendering ending. Now, however, all of the content is available with fairly rich markup: https://redbot.org/?uri=https%3A%2F%2Ftwitter.com%2Facdha%2Fstatus%2F578935560187826176 https://redbot.org/?uri=https%3A%2F%2Ftwitter.com%2Facdha%2F...

> "If it doesn't load through curl, it's broken." --someone So, so true. Thanks, curl.

by xrstf 12y ago

> "If it doesn't load through curl, it's broken." --someone So, so true. Thanks, curl.

That's pretty much my own test for a Web based API - if I can drive it from the command line using curl then great, if I can't then it's broken.

laurent123456 12y ago

Curl is great and all but I don't think this quote makes much sense. Are there examples of services that would, for example, load in a browser but not through curl? I'd think it's rather the opposite since you can through pretty much anything at curl and it will work.

cmg 12y ago
Anything that requires JavaScript to fetch and display content.
- VMG 12y ago
  Well somebody tell Google and Facebook, they're probably missing out on a lot of revenue because of their broken websites.
  - Piskvorrr 12y ago
    Broken != unprofitable.
  - Millennium 12y ago
    Website != API. A cleverly-written API can exist in the same space as a Website (even the same URLs, if you differentiate by things like Accept: headers), but they're not the same thing. It's perfectly acceptable for Websites to include, and even require the use of, JavaScript. It's also perfectly acceptable to offer a JavaScript client for your API. In fact, you pretty much have to do that if you want your Website to work with the API anyway. What's not OK is for an API to require downloading and using additional JavaScript while the API is being used. As a contrived (and somewhat ludicrous) example, let's say that I queried "http://foo.com/bars" http://foo.com/bars" for some kind of collection. It's OK to return the collection. It's even OK to use an HTTP redirect if the collection actually resides elsewhere: HTTP 302, perhaps, with a Location of "http://foo.com.bazes" http://foo.com.bazes". What's not OK is to return a line of JavaScript reading "window.location = 'http://foo.com/bazes';" http://foo.com/bazes';" which might work for the browser, but wouldn't work for most other clients.
- twerquie 12y ago
  Yeah, building web apps this way is a fad. I predict everyone will go back to full page reloads and server-rendered content. /s
  - acdha 12y ago
    On a serious note, “progressive enhancement – still the right way”. I don't think client-side rendering is going away but everyone who's relied on it exclusively has learned the hard way that it's just too unreliable and slow to have a failure mode which is an empty page unless a lot of complex code works perfectly. Just think about how many engineer-hours Twitter flushed with that silly #! kludge – and then when they switched back, saw an 80% improvement in page load time.
    - ceejayoz 12y ago
      > Just think about how many engineer-hours Twitter flushed with that silly #! kludge – and then when they switched back, saw an 80% improvement in page load time. No hours were wasted, and they didn't really switch back. They're just using HTML5's History API on browsers that support it now. Essentially the same mechanism under the hood, just prettier URLs for it.
      - hartator 12y ago
        I think he was making reference to the DOM rendering in the twitter website which used to be on client side until recently when they have switched back to server side rendering. But, it's very similar to pre-rendering React components on the server then mounting it so it might not be a total waste, that was a fad that didn't make a lot of sense for the time though.
      - acdha 12y ago
        They did more than just switch to the history API. During that period, if anything went wrong, you saw a blank page and, of course, robots saw only the generic launcher HTML instead of any content. Now, here's what a tweet looks like without JavaScript enabled: https://www.dropbox.com/s/me7kinvje7ly781/Screenshot%202015-03-20%2019.42.30.png?dl=0 https://www.dropbox.com/s/me7kinvje7ly781/Screenshot%202015-... Here's what it looks with JavaScript enabled: https://www.dropbox.com/s/04pjdlkuht6t2ja/Screenshot%202015-03-20%2019.42.38.png?dl=0 https://www.dropbox.com/s/04pjdlkuht6t2ja/Screenshot%202015-... (The main difference would be that things like the search & menus are either interactive controls or simple links to basic HTML forms depending whether JavaScript loads) During the hashbang era you couldn't use a page without a full rendering ending. Now, however, all of the content is available with fairly rich markup: https://redbot.org/?uri=https%3A%2F%2Ftwitter.com%2Facdha%2Fstatus%2F578935560187826176 https://redbot.org/?uri=https%3A%2F%2Ftwitter.com%2Facdha%2F...