6 ms·

Are there any web developers here who didn't know these things? Are there any developers of any type who didn't? I'm not sure who the audience for this article

by almost 16y ago

Are there any web developers here who didn't know these things? Are there any developers of any type who didn't? I'm not sure who the audience for this article is meant to be but I'm guessing you won't find too many of them here.

imp 16y ago
I didn't know some of the unusual specifics, but then again, I don't think that I need to either. It seemed less like a tutorial on what every web developer needs to know than it was documentation on what every browser maker needs to know.
daleharvey 16y ago
I never knew about params, I know a few people who didnt know things like fragments dont get sent to the server, everyone gets encoding wrong at some point, and I know a lot of people dont really know how the base tags work Cheers for the article, handy quick reference.
- locopati 16y ago
  I didn't either - in path params seems like an interesting way to address issues that can come up when devising RESTful URL schemes (rather than relying on query params only).
  - blasdel 16y ago
    For fucks sake, there is no such thing as a RESTful URL scheme. 'Pretty' URLs are a major anti-pattern -- they not only don't make you any more RESTful, they actively undermine HATEOAS, which is the true signifier of RESTfulness. Actual REST treats URL strings (including query parameters) as being completely opaque implementation details. The server is supposed to respond with URLs in the hypertext -- you're never supposed to be formatting them yourself client-side using out of band knowledge. Query parameters are no exception to that: if you want the client to pass them, give the client a form in the response. If you're expecting a client to munge together "path components" based on foreknowledge of your data model, you're doing it wrong.
    - stephenjudkins 16y ago
      Thank you! This is a very common misconception. A lot of folks have a conception of REST that is more or less completely the opposite of Fielding's. That said, I like pretty URLs. But they should be pretty for human beings and opaque for computers.
    - WesleyJohnson 16y ago
      Any chance you have articles to back this up? Not that I doubt you, but I've never really understood or looked into all this REST business and if I'm ever going to do so, I'd like to learn what being RESTful really means --- and not just jumping on what sounds like a bandwagon for 'Pretty URLs' as you mentioned. :)
      - adoyle 16y ago
        http://tech.groups.yahoo.com/group/rest-discuss/ http://tech.groups.yahoo.com/group/rest-discuss/
    - bluesnowmonkey 16y ago
      How are you supposed to represent collections, if every link must be provided by the server? I've seen REST examples where you give some results and a link to the next page of results. That's impractical if you have a million pages.
      - blasdel 16y ago
        If your collection is truly random access (array, search results, relational sets) then use a form that takes the 'foreign key' as input. Then there's one URL and standard query parameters. In pretty much all other cases a collection would have data/metadata in the response that far outweighs the links. And given that it's perfectly fine for the links to be completely opaque, there's no reason for them to be very long. The real problem with pagination is that all but a few brave souls completely fuck up the implementation of it. This is the worst possible way to paginate something, but just about every webapp ever written does it like this: SELECT * FROM posts ORDER BY date DESC LIMIT x OFFSET n*x The locations of items on pages change constantly as new items are created and destroyed! You page through the history (usually via links with the worst possible names: prev & next), and the items shift around as you move around. It's OK that the page with the most recent items changes as new ones are created, but having the archives be a pushdown stack is just idiotic. Shit would be less fucked if the pages would count up instead of down -- with the oldest items on page 1 and the newest on page N: http://www.dehora.net/journal/2008/07/20/efficient-api-paging-count-down-not-up/ http://www.dehora.net/journal/2008/07/20/efficient-api-pagin... It would be terrific if people used meaningful pagination instead of arbitrary offsets: posts by year/month/week/day/hour/minute/second/etc. is far better than "Page N" -- you don't even need to give me any options, just use older/newer links that point to the level of granularity that would give an appropriate number of results.
cldwalker 16y ago
If you read his other posts, they tend to state the obvious. Why this made it on HN perplexes me as well.
dkarl 16y ago
I never knew any of this stuff until I looked at the Javadoc for the Java URL classes. I'm not a web developer, but web developers aren't the only developers who use URLs, of course.
stephenjudkins 16y ago
I thought I knew these things until I worked on a project to scrape arbitrary websites. We had to follow arbitrary links around a site (easy, right?) but it turns out there are many, many edge cases we had to deal with. Another developer pretty quickly decided to ditch Ruby's URL parser and write our own, since there are tons of things browsers deal with that you wouldn't think of. For example, relative links starting with "//" share only the protocol (http or https) between the current page. Add in vagaries specific to some HTTP servers, like that http://foo/bar http://foo/bar == http://foo/bar/ http://foo/bar/ and we quickly realized it was a lot bigger task than we thought. We ultimately got the thing working OK, but crazy edge cases just kept popping up.

by almost 16y ago

imp 16y ago

I didn't know some of the unusual specifics, but then again, I don't think that I need to either. It seemed less like a tutorial on what every web developer needs to know than it was documentation on what every browser maker needs to know.

daleharvey 16y ago

I never knew about params, I know a few people who didnt know things like fragments dont get sent to the server, everyone gets encoding wrong at some point, and I know a lot of people dont really know how the base tags work Cheers for the article, handy quick reference.

locopati 16y ago
I didn't either - in path params seems like an interesting way to address issues that can come up when devising RESTful URL schemes (rather than relying on query params only).
- blasdel 16y ago
  For fucks sake, there is no such thing as a RESTful URL scheme. 'Pretty' URLs are a major anti-pattern -- they not only don't make you any more RESTful, they actively undermine HATEOAS, which is the true signifier of RESTfulness. Actual REST treats URL strings (including query parameters) as being completely opaque implementation details. The server is supposed to respond with URLs in the hypertext -- you're never supposed to be formatting them yourself client-side using out of band knowledge. Query parameters are no exception to that: if you want the client to pass them, give the client a form in the response. If you're expecting a client to munge together "path components" based on foreknowledge of your data model, you're doing it wrong.
  - stephenjudkins 16y ago
    Thank you! This is a very common misconception. A lot of folks have a conception of REST that is more or less completely the opposite of Fielding's. That said, I like pretty URLs. But they should be pretty for human beings and opaque for computers.
  - WesleyJohnson 16y ago
    Any chance you have articles to back this up? Not that I doubt you, but I've never really understood or looked into all this REST business and if I'm ever going to do so, I'd like to learn what being RESTful really means --- and not just jumping on what sounds like a bandwagon for 'Pretty URLs' as you mentioned. :)
    - adoyle 16y ago
      http://tech.groups.yahoo.com/group/rest-discuss/ http://tech.groups.yahoo.com/group/rest-discuss/
  - bluesnowmonkey 16y ago
    How are you supposed to represent collections, if every link must be provided by the server? I've seen REST examples where you give some results and a link to the next page of results. That's impractical if you have a million pages.
    - blasdel 16y ago
      If your collection is truly random access (array, search results, relational sets) then use a form that takes the 'foreign key' as input. Then there's one URL and standard query parameters. In pretty much all other cases a collection would have data/metadata in the response that far outweighs the links. And given that it's perfectly fine for the links to be completely opaque, there's no reason for them to be very long. The real problem with pagination is that all but a few brave souls completely fuck up the implementation of it. This is the worst possible way to paginate something, but just about every webapp ever written does it like this: SELECT * FROM posts ORDER BY date DESC LIMIT x OFFSET n*x The locations of items on pages change constantly as new items are created and destroyed! You page through the history (usually via links with the worst possible names: prev & next), and the items shift around as you move around. It's OK that the page with the most recent items changes as new ones are created, but having the archives be a pushdown stack is just idiotic. Shit would be less fucked if the pages would count up instead of down -- with the oldest items on page 1 and the newest on page N: http://www.dehora.net/journal/2008/07/20/efficient-api-paging-count-down-not-up/ http://www.dehora.net/journal/2008/07/20/efficient-api-pagin... It would be terrific if people used meaningful pagination instead of arbitrary offsets: posts by year/month/week/day/hour/minute/second/etc. is far better than "Page N" -- you don't even need to give me any options, just use older/newer links that point to the level of granularity that would give an appropriate number of results.

cldwalker 16y ago

If you read his other posts, they tend to state the obvious. Why this made it on HN perplexes me as well.

dkarl 16y ago

I never knew any of this stuff until I looked at the Javadoc for the Java URL classes. I'm not a web developer, but web developers aren't the only developers who use URLs, of course.

stephenjudkins 16y ago

I thought I knew these things until I worked on a project to scrape arbitrary websites. We had to follow arbitrary links around a site (easy, right?) but it turns out there are many, many edge cases we had to deal with. Another developer pretty quickly decided to ditch Ruby's URL parser and write our own, since there are tons of things browsers deal with that you wouldn't think of. For example, relative links starting with "//" share only the protocol (http or https) between the current page. Add in vagaries specific to some HTTP servers, like that http://foo/bar http://foo/bar == http://foo/bar/ http://foo/bar/ and we quickly realized it was a lot bigger task than we thought. We ultimately got the thing working OK, but crazy edge cases just kept popping up.