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.
The "verb" and "noun" terminology is somewhat unfortunate here. As you already mentioned, you can easily create object for function. All object oriented languages except Java have that transformation built-in and in Java you end up doing it all the time anyway ending up with lots of objects with single method and often one called "invoke", "execute", "apply" or somesuch (so it's the programming languages where the "verb"/"noun" distinction actually doesn't make sense).
The "verbs" of REST is more like classifying your methods to getters, setters (deleters; can be considered kind of setters) and other. And trying to do everything with getters and setters. The reason for this is:
- Easier semantics in face of communication failure, since both getters and setters are idempotent. Getting the resource twice has no additional effect and nor does setting it to the value it already has.
- Defining some semantics that can be used by possibly caching proxy that does not understand the specific interface. Getters are cached and setters are known to invalidate the cache.
HTTP was designed from the beginning with both caches and fault-tolerance in mind, so these two points lead to it's four basic methods:
GET is a getter. It's assumed not to modify server state and return the same value each time with possibility to specify expiration and revalidation policy.PUT and DELETE are the setter and deleter (= setter with nil). They are not normally used in context of normal web, but make sense for REST.POST is a generic "invoke" kitchen sink for which caches can assume nothing.
REST is a design pattern describing how to use raw HTTP or similar network protocols to implement interface that allows easy handling of failures by simple retrying and works nicely with caching proxies.
It doesn't correspond easily to regular object-oriented programming API. I think it is actually a good thing. The challenges of interfacing over network, which is inherently unreliable and where round-trips are much slower than transferring even moderate amount of data call for different design approach than in-process API, so when it looks different, people don't try to apply invalid experience from the other domain that much (that's the bane of SOAP, XML-RPC and such; it looks like procedure calls, but doesn't work like it and ends up being pain to work with).
Best Answer
There are two authorization models that are common: trusted subsystems and delegation.
There are tradeoffs between these two approaches; trusted subsystems is an easier architecture easier to implement, but delegation enables more advanced security features. For your application, it is likely much easier to follow the trusted subsystem strategy, so I would strongly consider building authn/authz at the API "facade" (maybe gateway is a better word here?).
EDIT: The answer depends heavily on what the message service is doing, and what data is required for it to carry out its duties. If the message service is just routing messages in realtime to websockets, the requirements may be different than if the messages are persisted to a database. In general, though, it's possible that the service interacts with user IDs without being directly coupled to the user service (e.g. storing the messages in a table as sender_id, recipient_id, and message).
Check out this post for more on delegation and traversing layers.