A previous answer only mentioned SSL in the context of data transfer and didn't actually cover authentication.
You're really asking about securely authenticating REST API clients. Unless you're using TLS client authentication, SSL alone is NOT a viable authentication mechanism for a REST API. SSL without client authc only authenticates the server, which is irrelevant for most REST APIs because you really want to authenticate the client.
If you don't use TLS client authentication, you'll need to use something like a digest-based authentication scheme (like Amazon Web Service's custom scheme) or OAuth 1.0a or even HTTP Basic authentication (but over SSL only).
These schemes authenticate that the request was sent by someone expected. TLS (SSL) (without client authentication) ensures that the data sent over the wire remains untampered. They are separate - but complementary - concerns.
For those interested, I've expanded on an SO question about HTTP Authentication Schemes and how they work.
A simple RESTful pattern for batches is to make use of a collection resource. For example, to delete several messages at once.
DELETE /mail?&id=0&id=1&id=2
It's a little more complicated to batch update partial resources, or resource attributes. That is, update each markedAsRead attribute. Basically, instead of treating the attribute as part of each resource, you treat it as a bucket into which to put resources. One example was already posted. I adjusted it a little.
POST /mail?markAsRead=true
POSTDATA: ids=[0,1,2]
Basically, you are updating the list of mail marked as read.
You can also use this for assigning several items to the same category.
POST /mail?category=junk
POSTDATA: ids=[0,1,2]
It's obviously much more complicated to do iTunes-style batch partial updates (e.g., artist+albumTitle but not trackTitle). The bucket analogy starts to break down.
POST /mail?markAsRead=true&category=junk
POSTDATA: ids=[0,1,2]
In the long run, it's much easier to update a single partial resource, or resource attributes. Just make use of a subresource.
POST /mail/0/markAsRead
POSTDATA: true
Alternatively, you could use parameterized resources. This is less common in REST patterns, but is allowed in the URI and HTTP specs. A semicolon divides horizontally related parameters within a resource.
Update several attributes, several resources:
POST /mail/0;1;2/markAsRead;category
POSTDATA: markAsRead=true,category=junk
Update several resources, just one attribute:
POST /mail/0;1;2/markAsRead
POSTDATA: true
Update several attributes, just one resource:
POST /mail/0/markAsRead;category
POSTDATA: markAsRead=true,category=junk
The RESTful creativity abounds.
Best Answer
Yes, it does! From my testing on my server I can get 300 calls per seconds to my REST web service without keepalive, over 2000 with the keepalive on.
You will have to do some analysis on the usage patterns - often user-driven usage comes in bursts so it makes sense to keep the keepalive timeout quite short, just to handle a single burst.