REST API - Generic or specific resources

Question

I am currently working on a project that has a resource for sending things.

Let's say the URI looks like this http://api.somename.com/thingssender with only the POST verb.

Over time this has become a resource that in the payload has several 'optional' elements that only apply to sending one type of thing.

Currently this resource handles two different types of things (ThingA and ThingB) but also varies on the content in a sub-element. So for example you can send many things or a single thing to a group of people.

A requirement has emerged that a ThingC is required. Given that this endpoint is likely to take a ThingD in the future with optional data in the payload, I'm starting to question this 'catch-all' resource.

I'm worried that the resource will keep growing in complexity not only for developers but for the clients using the REST API. To me this will just cause confusion and not create the best experience (again for both developer and client).

What are peoples thoughts on creating a generic endpoint versus a specific endpoint?

So a specific endpoint for sending ThingCs (http://api.somename.com/ThingsCSender). It screams single responsibility to me and with careful consideration to the underlying implementation should not cause any repeteated functionality.

(The examples given are not real concepts or resources in the project :p !)

Cheers

Answer 1

You are correct in the fact that each resource should have its own URI. For more information, if interested there are some great answers on stackoverflow:

Understanding REST: Verbs, error codes, and authentication

What exactly is RESTful programming?