If you wanted to start a 'website' that could be accessible from multiple 'endpoints'. Is it a good idea to design from a REST perspective from the begining?
I'm thinking that the answer is 'yes' ... but are there other opinions?
Should REST be your 'starting point' for the design of systems that are hopefully extensible and also accessible in ways that aren't defined?
I would say yes, so long as nothing about your application would require you to work against the basic constraints of REST.
I think it's much easier to start out thinking RESTfully, then it is to later on try and add or replace a SOAP web service with a RESTful one.
Start by identifying the resources you will be serving up, your "nouns". Then determine how they would be organized in your URI space. Think of the actions users will take against these resources and how the fit/don't fit with the basic HTTP verbs.
I would suggest the best starting point is the data model. Carefully thinking through what data you will store and how it relates to other data is the most important aspect. Once a solid foundation has been set for the model, exposing it via REST, SOAP, RSS, ATOM, etc. to multiple consumers is much easier.
Because you are using the words "could" and "hopefully" and (especially) "not [yet] defined", I would have to say: probably not.
Maybe you need a REST interface next month or next year, but maybe it turns out you don't need one at all! Of course, if you can make your technical decisions in such a way that you keep the door open for a future REST service, then by all means do that.
Create what you need now, not what you think you will need. This is a very common (but costly) error.
REST is just an architecture, it's not a religion or the higher purpose of the web. Use it if it seems appropriate to your problem domain. Otherwise, use some other solution. REST is not meant to be used for all web development.