Rest – URLs with variable query strings and cache

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.

Setting the max-age to 8 days instead of 1 year gives Google better control over the way it presents itself to the world. You're right that they can simply use a different URL for temporary changes like the Google doodle, but if they think they might want to change the way their real corporate logo appears, it makes sense to use a shorter expiration time for two reasons:

1. Any references to their logo on any of their existing pages will change automatically -- no need to modify them to use a different URL.

2. The countless third party web pages that load Google's logo will display the new version automatically after 8 days or less.

Furthermore, longer expiration times provide diminishing returns. With no caching, a typical user might load Google's logo a thousand or more times each year. An 8 day expiration cuts that down to 46 times a year. A 1 year expiration further reduces that to potentially as little as 1 time each year. It seems like the largest benefit, by far, is due to the fact that the image is cached at all -- caching for just 1 day provides a huge benefit, and caching for 8 days extends that somewhat.

The image above is only 7007 bytes in size. Loading that every 8 days means that you're loading 312 kilobytes of their logo over the course of a year. That's really not a lot as a percentage of all the data you load from Google, and the good folks at Google have apparently made a decision that the flexibility they gain from the 8 day expiration is more important than reducing that number further. If they thought otherwise, you can bet they'd use a longer expiration time.

I don't work at Google, and even if I did I probably wouldn't be in a position to know their reasoning for certain, so the above is somewhat speculative. The real answer could be something as simple as: it seemed like a good idea at the time. Nevertheless, there's obviously a tradeoff between minimizing traffic and creative control, and I think we can tell from the expiration time that Google uses where they wanted to draw that line.

Also, I think it's worth noting that Google's isn't just any logo: it's the main feature on their most important web page, and it's presentation is something that they're known to be very careful about. The other sites that you mention (BBC, YouTube, Twitter, and Yahoo) all include their logo on their main page, but in each case the logo is smaller and a much less important element of the page than Google's is. Google has also made a number of changes to its logo over the years (no, I'm not talking about doodles), and there's no reason to think that they won't do it again.