What does the Spring framework do? Should I use it? Why or why not?
Spring is a framework that helps you to "wire" different components together. It is most useful in cases where you have a lot of components and you might decide to combine them in different ways, or wish to make it easy to swap out one component for another depending on different settings or environments.
This is what I've always understood "dependency injection" to be.
I would suggest a different definition:
"Design your objects so that they rely on an outside force to supply them with what they need, with the expectation that these dependencies are always injected before anybody asks them to start doing their usual jobs."
Compare that against: "Each object is responsible for going out and finding everything and everybody it needs as it starts up."
it looks like it necessitates a whole bunch of XML configuration
Well, most of the XML (or annotation-based) stuff is telling Spring stuff like:
- When someone asks for "HammerStore", I want you to create an instance of
example.HammerStore and return it. Cache the instance for next time, since there only needs to be one store.
- When someone asks for "SomeHammer", I want you to ask yourself for a "HammerStore", and return the result of the store's
makeHammer() method. Do not cache this result.
- When someone asks for "SomeWrench", I want you to create an instance of
example.WrenchImpl, Use the configuration setting gaugeAmount and put it into the instance's setWrenchSize() property. Do not cache the result.
- When someone asks for "LocalPlumber", I want to you create an instance of
example.PlumberImpl. Put the string "Pedro" into its setName() method, put a "SomeHammer" into its setHammer() method, and put a "SomeWrench" into its setWrench() method. Return the result, and cache the result for later since we only need one plumber.
In this way, Spring lets your connect components, label them, control their lifecycles/caching, and alter behavior based on configuration.
To facilitate [testing] I typically make (at least) two versions of a method : one that uses instance variables, and one that only uses variables that are passed in to the method.
That sounds like a lot of overhead for not a lot of benefit for me. Instead, make your instance variables have protected or package visibility, and locate the unit tests inside the same com.mycompany.whatever package. That way you can inspect and change the instance variables whenever you want during testing.
A chat service as a rest-ful api is a GOOD match !
I think resource-based interfaces are still a very important concept to talk about. The above answer is just not correct, even though it is over 4 years old.
In general, really NOTHING is wrong about building a chat server interface as an resource oriented ReST-ful API. It is absolutely valid and a very good match for the principle.
There are even example and tutorial pages out there, that use this as a quite straightforward example to emphazise the intention behind ReST-ful API.
Why it is GOOD
It can be a forum like service or a "realtime" chat, it does not matter in this regard. It boils down to the domain model.
EXAMPLE 1 (classic realtime chat):
Be it a more elaborate chat service, then one needs to create a chat room. The chatroom will be attached to him/her (the user object) and the chatlobby enclosing it (just assumed).
One can now either check the user resource or the chatlobby resource, or filter through chatroom resources via additional query-params, what is perfectly valid.
Which post the client has lately viewed and stuff like this, as long as it is not modelled in our chat service domain, is not part of the server state like mentioned in wikipedia. This is the "session" state of the client, the client tells which part of the collection of chat message resource it wants to GET.
So how dare one says that it does not match !!
For the forum like chat it is even simpler.
EXAMPLE 2 (forum like chat):
A "chat" forumPost is a Domain Object aswell as a comment on this forumPost. Surely then they will need a unique identifier to allow for a unique resource identifier (URI).
One can even see that this looks quite similar to the above example. It is generally a good example, however you want to turn the chat.
With an AOP audit you get created and modified times injected, can handle authorization ...
The core aspect is, that this kind of api makes it necessary to understand the domain and the fundamental parts that matter to the user, the consumer, or interacting applications in general.
STATELESS AND STATEFUL:
It is really important to keep the principles in mind.
The stated Wikipedia entry on ReST and the paragraph on STATELESS communication is aimed towards the client state, not the state of domain objects. Resources aka domain objects are by definition STATEFUL.
The paragraph referenced is about session state, not domain state.
If you intend to develop enterprise software, it is crucial to keep the boundaries and rationales straight.
IN A NUTSHELL:
Comments and Posts, aswell as Users are perfect examples for a restful api.
For this reason a chat service is absolutely fine to start with.
Having a seqential identifier will definitely not hurt.
Go further and try to use links for the relations (href) and define the relation via (rel) relation attribute. Then the client can use domain terms to consume the correct endpoints.
The client can via this technique (HATEOAS) explore the entire graph of objects without any knowledge of the domain objects themselves.
Hope this helps to clarfiy, even though this is an older entry, the topic is still absolutely recent.
Best Answer
I've grown to love Dropwizard for an overall solution
Rather than go with some huge application container approach, Dropwizard advocates a lightweight solution that offers much faster development cycles. Essentially, it provides the glue for the following well-known frameworks:
The combination of the above, coupled with a solid approach to functional testing, gives a complete solution to getting your service up and running quickly.
Yeah? And the JAX-RS question I asked...
You'll notice that their choice was Jersey, the reference JAX-RS implementation. Being a RESTEasy guy I thought this would be a problem, but there was zero learning curve. The two are largely interchangeable. However, I would say that the Jersey client offered a fluent interface for constructing tests. An example would be...