Design Issue: Service layer/ trying to maintain RESTful architecture

Question

I'm trying to design a web-application - and after doing a lot of reading on REST + design patterns, I'm at a loss on how to handle my requirements. I think I may be getting caught-up in all the design-patterns, but at the same time want to produce a well-architect-ed design.

I have 2 major business-objects, Customer and Order, with a Has Many relationship. Currently, I have no service layer, and the REST API is in the BL:

GET Customers GET Orders
GET Customers/id GET Orders/id
POST Customers POST Orders
PUT Customers/id PUT Orders/id
DELETE Customers/id DELETE Orders/id

But things become hard to design when I have to architect for legacy means of user-data input, and well as for the future:

• Now: Users upload an Excel .xlsx file containing Customer, Order information, which I parse, extract, create Customer/Order business-objects for, and perform validations. In order to have a pleasant User-experience, I don't save these objects right away, I return them to the User (along with any errors from the verifications) so they may make any needed changes before finally submitting them. (this 2-step submission just adverts the requirement of correcting sources of any validation errors directly in the Excel file).
• Future: Customer/Order data will be maintained, and uploaded, through a web service/platform.

I don't know how to handle these requirements gracefully, and intelligently. Is this a case where I need to expose a Service Layer that publishes an interface for the soon-to-be-legacy Excel-upload, as well as an interface for the web service?

Any design help would be appreciated, as I'm rather new to this type of development and rather not make a major architectural mistake that will come back to bite me later..

Thanks in advance.

edited as comments suggest

• Mike Partridge: I don't have experience with this situation, so just a note: when the client knows the resource's ID (i.e. Customers/id, Orders/id), inserts/update should use PUT rather than POST. stackoverflow.com/questions/630453/put-vs-post-in-rest
• Robert Harvey: @MikePartridge: According to this article, idempotency is the determining factor. I actually agree with the link you posted, which says that PUT is basically for upserts, while the effect of a POST is defined by the server and can basically be anything. That would be consistent with idempotency, however; PUT is idempotent, POST is not.
• Mike Partridge: Indeed. My earlier comment simplifies the topic, but I think my point follows from the idempotancy of PUT.
• NoChance: Why are you using a service anyway?
• Colin Martell: @EmmadKareem What do you mean? You mean the Future source of data input? We want to integrate with SalesForce.com

Answer 1

I think the simplest path would be to create a RESTful interface around your business objects and then code a small service with the purpose of taking an spreadsheet, parsing it, and making the appropriate calls against your RESTful service.

No matter which route you take you will have to create the RESTful portion as well as the spreadsheet handling portion (or maybe that's already written). It only seems logical to code the spreadsheet portion against your final API. This will also give you an early peak into using your API and possibly point out some issues or shortcomings that were overlooked in the planning stages.

• Colin Martell: Yes, this is what I was thinking of doing - just wanted some verification that it was a sensible thing to do