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!

Improve this question
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? Commented Dec 10, 2020 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. Commented Dec 10, 2020 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. Commented Dec 10, 2020 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. Commented Dec 10, 2020 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.) Commented Dec 10, 2020 at 9:01

1 Answer 1

Reset to default
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.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.