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.
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:
- Jetty (HTTP)
- Jersey (JAX-RS)
- Jackson (JSON or XML)
- Guava (excellent additions to JDK libraries)
- Metrics (real time application monitoring)
- Hibernate Validator (input verification)
- OAuth (RESTful authentication)
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...
@Override
protected void setUpResources() {
addResource(new HelloWorldResource("Hello, %s!","Stranger"));
setUpAuthenticator();
}
@Test
public void simpleResourceTest() throws Exception {
Saying expectedSaying = new Saying(1,"Hello, Stranger!");
Saying actualSaying = client()
.resource("/hello-world")
.get(Saying.class);
assertEquals("GET hello-world returns a default",expectedSaying.getContent(),actualSaying.getContent());
}
Best Answer
Sounds like a bad idea. For one thing, the Date constructor that you'd be relying on has been deprecated since Java 1.1 in favor of DateFormat.parseDate(), precisely because it's unclear how strings should be parsed into dates, as the rules are different for different localities.
My recommendation would be to stick with a specific format, preferably the internationally understood yyyy-MM-dd, and use a DateFormat to parse the date from a string inside your service, which makes it clear how to consume the web service, and allows you to follow whatever the standard convention for returning error messages is for your web services when something goes wrong.