Hacker News Reader

Comment by feral | Hacker News Reader

When I was defining our API at Synference, I looked this up.

As far as I'm concerned, pragmatically, its using the HTTP verbs to operate on resources, named according to a certain URL convention (e.g. users/<userid>), when the semantics of the verbs are followed.

E.g. GET shouldn't change resource state; POST should be used to create a new resource (which the server will typically name); PUT should be used to update an existing named resource, etc.

What format of data sent using these verbs can vary - JSON is one popular format, and what I'd choose.

However, in practice, when people say their API is RESTful, it often just means 'you can access our API over HTTP'. Often you see everything implemented as GET requests - for better or worse.

And there are some pragmatic reasons for that - e.g. maybe devs decide they want to use JSONP to get around same origin restrictions; there's web developers out there who can only make GET requests, etc.

View on HN

Just to ride on this, the "named according to a certain URL convention" isn't a set thing. You can have any convention as long as it's the same everywhere.

What is a resource exactly? Is GET /sumof/2/5 -> 7 a resource?

I think the word "resource" is a source of confusion. It doesn't make any sense to mortals.

Yes! You hit the nail on the head.

You can think of "resource" as an object in your application exposed on the web. REST actually talks about "resource representations" not: resources per se. This has to do with the Facade pattern and not tying your public interface with your internal implementation.

That said, for getting started you can think as "resource" being a web-addressable representation of an object in your application.

Yes in principle, but that's a dumb way to do it. A client programmer might infer something generalised from this example and be tempted to hard-code /sumof in his user agent, which makes the server lose controls of its URI namespace, which in turn the prevents the affair from being RESTful.

Instead, you express your summing service with a hypermedia control. In HTML you have forms, which is a perfectly fine and very interoperable way; look at all the deployed software understanding HTML forms! Another control fitting the example here is to send the client an RFC 6570 URI template (I'm uncertain of the correct syntax with the * in detail here, sorry, take this as illustration only):

    Link: </sumof/{summand*}>;
        rel="http://RivieraKid.example.net/summing_service";
        title="RivieraKid's summing service";
        hreflang="en";
        type="application/hal+json; profile=http://RivieraKid.example.net/"

Note that the server can change the URI any time (and hopefully forward to the new address with a 3xx response), the client only needs to be taught the semantics of the link relation and the media type. The rest is plain internet standards.

slashdotaccount, hit me up on twitter @pfrazee. I think we're looking at the same ideas

Reply on news.ycombinator.com