Re:Ask HN: What is REST exactly?
by krainboltgreene on Saturday February 08, 2014 @03:02PM
(#7202405)
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.
Re:Ask HN: What is REST exactly?
by RivieraKid on Saturday February 08, 2014 @03:11PM
(#7202453)
What is a resource exactly? Is GET /sumof/2/5 -> 7 a resource?
Re:Ask HN: What is REST exactly?
by slashdotaccount on Saturday February 08, 2014 @03:29PM
(#7202541)
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/"
slashdotaccount, hit me up on twitter @pfrazee. I think we're looking at the same ideas
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.
I think the word "resource" is a source of confusion. It doesn't make any sense to mortals.
Re:Ask HN: What is REST exactly?
by RivieraKid on Saturday February 08, 2014 @03:38PM
(#7202588)
Yes! You hit the nail on the head.
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.