1

Edited Question based on the comments and great feedback (thanks)

I have a REST controller exposing two GET endpoints.

  • GetById - taking a single id (string)
  • GetById - taking multiple id's (a collection of type string)

The only thing the controller does is call the service/domain layer which also exposes the GetById method. Both of these methods are part of the public interaface of the service layer.

The question is in regards to design, is it a good choice to force the client to create a collection from a single string e. g. new {myId}, or should the public API support both of these methods?

Original Question

I am currently facing the following situation. I have a REST Controller which accepts a single string (an id). This id is then passed to the underlying service layer which has a method also taking one string (the id).

Now I have the requirement to also accept multiple id's. The REST controller must accept multiple id's, however my question is, should the service layer provide now only one method taking multiple id's (List/Enumerable) or should the method be overloaded with both, a single string and a collection?

Thank you!

5
  • If you overload it, will there still be a client for the method with a single string argument? In other words, is there a reason for having two methods?
    – Rik D
    Dec 10 '20 at 8:05
  • Hey @Rik D, at the moment not. For me the question is also if it is okay for any potential clients to wrap a single id into a collection or if the service should expose/provide this.
    – lucniner
    Dec 10 '20 at 8:22
  • What does "should" mean here? Are you trying to fit into some programming pattern, framework, or paradigm? Are you just looking for pros and cons of method overloading in general? There's not really much specific information in your question to say what applies specifically to your situation, and a lot of room for style and opinion.
    – IMSoP
    Dec 10 '20 at 8:42
  • "if it is okay for any potential clients to wrap a single id into a collection" - that's OK. Regarding exposing a single ID version: nobody can tell you what to do in general terms, you're the one who understands the needs of your application best. If the typical usage scenario is multiple IDs, then only having the multiple ID version is probably preferable. Dec 10 '20 at 9:00
  • 1
    Since currently there aren't any single-ID clients, I would leave it at that. Don't try to predict the future (YAGNI); if single-ID usage becomes common later on, you can expose another endpoint, and (e.g.) internally wrap the param into a singleton array, and then call the other method (or refactor to go the other way around if single-ID scenarios become the most common, or decide to have separate implementations, etc.) Dec 10 '20 at 9:01
1

First of all, having both is ok. There's nothing wrong in it. Don't overthink this too much.

If it doesn't make you feel comfortable. The only we can say is. It depends.

If removing the existing method doesn't cause a breaking change or if it does but it's in your hand to solve it (and it's affordable) then remove it. If not, keep it.

An alternative could be keeping the existing method and make it compatible with different input formats. Instead of handling single ids (0001) you could support multiple comma-separated values (0001;0002;000n) and tokenize the input (turn a string into an array) and iterate.

It's not the most elegant way to do this. But it's the one that doesn't cause your API consumers to change the endpoint or the request body depending on the number of inputs. It's always 1 string which might bear 1 or more ids. It could be challenging tho if these IDs have commas, semicolons, or other possible CSV delimiters that might alter the tokenization of the input. But still, it would be possible with the proper deserialization.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.