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

  • 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 Commented Sep 30, 2013 at 16:58
  • @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. Commented Sep 30, 2013 at 17:03
  • Indeed. My earlier comment simplifies the topic, but I think my point follows from the idempotancy of PUT. Commented Sep 30, 2013 at 17:12
  • Why are you using a service anyway?
    – NoChance
    Commented Sep 30, 2013 at 17:40
  • @EmmadKareem What do you mean? You mean the Future source of data input? We want to integrate with SalesForce.com Commented Sep 30, 2013 at 17:50

1 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.

  • Yes, this is what I was thinking of doing - just wanted some verification that it was a sensible thing to do Commented Oct 1, 2013 at 15:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.