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

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 – Colin Martell Oct 1 '13 at 15:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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