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

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.

Yes! You hit the nail on the head.