How I learned to stop worrying and love REST • Hacker News Board

Re: How I learned to stop worrying and love REST

#21

Post by grncdr » Mon, Feb 06, 2012, 1:11 AM UTC

mseebach wrote: post #20

noblethrasher wrote: post #16

Earlier quoted context omitted.

Query parameters create hyperlink templates. So href="foo/bar/?baz=x" is really a way for generating a set of hyperlinks that range over whatever domain x comes from and the client should feel free to plug in any valid value for x. You can even indicate the domain of x by returning a 405 in the case of an invalid value (although it would be nice to have a standard way of indicating the domain beforehand) For instance…

I find URL templates smelly. Once you stick a place holder in the URL, it's no longer a valid URL - it's something that requires custom mangling before it can be passed along. In your example, I need to know that the x is something that requires replacement. How is that fundamentally different from just putting in your documentation (and, in the 405 if not passed) "this resources takes query param baz" - which is not…

> I find URL templates smelly. Once you stick a place holder in the URL, it's no longer a valid URL - it's something that requires custom mangling before it can be passed along.

This is why a standard has been drafted for this particular problem, the mangling becomes standard and predictable rather than customized to each use case.

http://tools.ietf.org/html/draft-gregorio-uritemplate-08

Re: How I learned to stop worrying and love REST

#22

Post by [deleted] » Mon, Feb 06, 2012, 1:12 AM UTC

mahmoudimus wrote: post #17

mseebach wrote: post #12

What is the HATEOS compliant way of accepting parameters? E.g. for the pagination example, you might want to let the consumer specify number of entries pr. page, or you might want to accept a search-term or limit by period.

I think you should have a pagination resource that understands a resource and returns a paginated URL. it would accept parameters. I think having a template requires the client to understand a format other than hypertext.

[deleted]

Re: How I learned to stop worrying and love REST

#23

Post by gotmayonase » Mon, Feb 06, 2012, 1:16 AM UTC

mseebach wrote: post #12

What is the HATEOS compliant way of accepting parameters? E.g. for the pagination example, you might want to let the consumer specify number of entries pr. page, or you might want to accept a search-term or limit by period.

According to Steve Klabnik, this can be accomplished via GET forms and using query templates: http://amundsen.com/media-types/collection/format/#query-tem...

Re: How I learned to stop worrying and love REST

#24

Post by vyrotek » Mon, Feb 06, 2012, 2:37 AM UTC

verelo wrote: post #6

I hate when people try tell me REST isnt the way to go. I guess if you're an out-dated organization with a lot of time (and money) on your hands, you could stuff around with something else...but why would you in this world as a startup do anything else? Nice article, i think the world needs a very basic "this is how you use REST" bullet point style blog post somewhere. This lesson would be 1 of those bullet points if…

Someone asked for some Dos and Don'ts here and started a nice list: http://news.ycombinator.com/item?id=3538392

Re: How I learned to stop worrying and love REST

#25

Post by methodin » Mon, Feb 06, 2012, 2:49 AM UTC

verelo wrote: post #6

I hate when people try tell me REST isnt the way to go. I guess if you're an out-dated organization with a lot of time (and money) on your hands, you could stuff around with something else...but why would you in this world as a startup do anything else? Nice article, i think the world needs a very basic "this is how you use REST" bullet point style blog post somewhere. This lesson would be 1 of those bullet points if…

Have you actually ever been a consumer of an extensive, pure REST API? At the point in time in which you are required to make a couple hundred requests in a single page in order to build something useful you'll start to wonder why it's touted so much.

Unless, of course, the company maintaining the API has the resources to have almost all requests cached and a responsible data design to facilitate accurate ETAG matching. If not... well you are going to be at the whim of their server architecture.

Even then, that's an incredible amount of calls to make just to display some information.

Re: How I learned to stop worrying and love REST

#26

Post by verelo » Mon, Feb 06, 2012, 3:03 AM UTC

lmm wrote: post #19

verelo wrote: post #6

I hate when people try tell me REST isnt the way to go. I guess if you're an out-dated organization with a lot of time (and money) on your hands, you could stuff around with something else...but why would you in this world as a startup do anything else? Nice article, i think the world needs a very basic "this is how you use REST" bullet point style blog post somewhere. This lesson would be 1 of those bullet points if…

>why would you in this world as a startup do anything else? Because the tech's immature and irrelevant to your core competency? The paragraph at the end of the HATEOAS page sums it up pretty well for me - and seems to be struggling to make the case for the benefits of "full REST". I despise the enterprisey verbosity of SOAP et al, but given the choice between an inefficient but well understood standard with good tool…

Yeah i guess you're right, i too get quiet frustrated by how verbose SOAP is and that's the true reason as to why i've personally avoided.

Having worked fairly extensively with the Facebook API in recent years i've just come used to dealing with REST API's (and honestly while they do a half decent job, it has a lot of shortcomings)

I just find the time to get a REST API up and running is very short, and for that reason it tends to be my choice. Not saying its the right one however :P

Re: How I learned to stop worrying and love REST

#27

Post by bodhi » Mon, Feb 06, 2012, 3:09 AM UTC

mseebach wrote: post #12

What is the HATEOS compliant way of accepting parameters? E.g. for the pagination example, you might want to let the consumer specify number of entries pr. page, or you might want to accept a search-term or limit by period.

There is actually a HTTP header (Range) that can be used for this. Works well in APIs but you can't do it with browsers, which is unfortunate.

Re: How I learned to stop worrying and love REST

#28

Post by shreyas-satish » Mon, Feb 06, 2012, 4:02 AM UTC

mmackh wrote: post #2

Disclaimer: I do not want to steal the author's page views, but I could hardly read this article, due to the white shadow in the Text. Here is a more readable view: http://rdit.in/5c

I suggest you try out Evernote Clearly http://www.evernote.com/clearly/ . It comes with a browser extension, using which you can convert a blurb of text that is difficult to read into an easily readable one.

Re: How I learned to stop worrying and love REST

#29

Post by [deleted] » Mon, Feb 06, 2012, 7:16 AM UTC

noblethrasher wrote: post #16

mseebach wrote: post #12

What is the HATEOS compliant way of accepting parameters? E.g. for the pagination example, you might want to let the consumer specify number of entries pr. page, or you might want to accept a search-term or limit by period.

Query parameters create hyperlink templates. So href="foo/bar/?baz=x" is really a way for generating a set of hyperlinks that range over whatever domain x comes from and the client should feel free to plug in any valid value for x. You can even indicate the domain of x by returning a 405 in the case of an invalid value (although it would be nice to have a standard way of indicating the domain beforehand) For instance…

[deleted]

Re: How I learned to stop worrying and love REST

#30

Post by buddydvd » Mon, Feb 06, 2012, 7:17 AM UTC

mseebach wrote: post #20

noblethrasher wrote: post #16

Earlier quoted context omitted.

Query parameters create hyperlink templates. So href="foo/bar/?baz=x" is really a way for generating a set of hyperlinks that range over whatever domain x comes from and the client should feel free to plug in any valid value for x. You can even indicate the domain of x by returning a 405 in the case of an invalid value (although it would be nice to have a standard way of indicating the domain beforehand) For instance…

I find URL templates smelly. Once you stick a place holder in the URL, it's no longer a valid URL - it's something that requires custom mangling before it can be passed along. In your example, I need to know that the x is something that requires replacement. How is that fundamentally different from just putting in your documentation (and, in the 405 if not passed) "this resources takes query param baz" - which is not…

It may smell, but clients that uses URL templates may still be RESTful. For this to work, 1.) the server must decorate the response with the proper resource type identifier, 2.) the client must be able to understand the resource type, and 3.) the resource type spec must specify how the clients should treat URL templates.

Web browsers are REST clients that understand the HTML resource type. They, too, can generate URLs. For example, in HTML, you can specify a URL template with the following code:

Input tags with type="text" are, by default, optional. Newer HTML spec allows you to annotate input tags with the "required" attribute, which allows you to specify them as required.

You can define your custom resource type to do the same if you want:

    { "form": { "action": "foo/bar/",
                "method": "GET",
                "fields": [ { "name" : "baz" } ]
    }

You can make the above example a lot leaner by trimming out features you don't care about. It's all up to how you design the spec of your resource type.