1

I'm new to web application development, and aiming at designing an application which will serve both browsers and mobile devices which will consume REST services to communicate with the server.

For this I think of creating 2 separate layers for web and rest. I follow the spring io getting started guides full tutorials (http://spring.io/guides#gs), which use an architecture that holds a domain package within the rest layer which constructs the objects that will be sent as replies to rest requests.

In another web tutorial they have a similar package under web layer for handling the domain objects prior to displaying them.

I read this question and if I follow the general guidelines in the answer, I would implement separate domain packages since even if the view layer uses REST, there are still some differences which might be a source of maintenance problems should I decide to change something in the future: (Best Practice - Multi Layer Architecture and DTOs)

My question is regarding an application that has both, should the web layer hold DTO's like the rest one, or is it a good practice to have the views call the rest services or use the same rest.domain.POJOs (and extract these POJOs from that package to a common one?

Thanks.

Community
  • 1
  • 1
omer keynan
  • 135
  • 1
  • 11
  • This is a much better fit for Programmers and too opinion-based for SO. That said, I attempt to use the same resource representations for JSON responses and HTML model attributes, since it helps ensure that the REST facade has consistent behavior regardless of what type of client is accessing it. – chrylis -cautiouslyoptimistic- Jun 09 '14 at 22:16
  • Have a look a Apache Olingo JPA Processor. – Hannes Jun 10 '14 at 04:32

1 Answers1

1

Considering the question tags, the simplest architecture that would achieve what you want would be a simple Spring MVC project that serves both the Web content and REST services. A more complex architecture might require some sort of a "commons" project that contains all models (DTOs), services, repository, utils, etc -- this would produce a JAR that could be consumed by both Web and REST projects.

If you don't need to scale Web/REST individually and don't need them on different release cycles/versioning, there's probably no need for them to be separate deployables. If the Web/REST components don't really have a need to exist on their own, don't over-engineer it.

I would lean heavily towards KISS and start with a single project, while making design decisions that facilitate moving to a more complex architecture if needed. For example, utilize packages to segment Web controllers from REST ones, separate the "commons" classes, use dependency management (e.g. Maven).

As for organizing your DTOs it's going to rely heavily on your use case. Use common models when possible, but don't be afraid to create light-weight models for Web or REST when needed.

ach
  • 6,164
  • 1
  • 25
  • 28
  • Thanks, ach. I'm not going to produce 2 packages. I was referring to the inner setup of the web layers. I got my answer from your hint "If you don't need to scale Web/REST individually and don't need them on different release cycles/versioning". This, combined with chrylis's comment on mainaining the consistency for access actually got me to realize that i want a single JSON representation for both resource consumer types, and a facade for each to access the objects. Thank you very much. – omer keynan Jun 10 '14 at 06:21