As best I can deduce your question can be restated as:
Why should I go through the Business Layer of a Service, when I can just insert the data directly into its database?
Lets contrast these two approaches.
The Two Approaches
If I go through the public interface to update the data.
- Its slower, the database is updated, but there is all these extra layers of code, data transformation, validation, and technologies.
- There are more components the could go down, such as the web service.
- A REST API resists the use case of streaming events.
- One set of Business rules applied to all incoming data.
- Decouples the event source from the backend details.
- Allows seperate teams to maintain the event source separately from web service.
If I go directly to the database.
- Any change to the database structure/engine has to consider compatibility with two separate code bases
- The Web Service has to be aware that the database is changing behind its back (essentially the database becomes a third codebase/service of its own distinct from the rest api, and the event source).
- Validation and business logic must be rewritten/shared between projects.
- The validation/business logic can be stream lined on a per project basis. The Event Source and the REST API need only know the pieces relevant to their circumstance.
A very short list of pros and cons, spend some time thinking up more...
Is picking between the two solutions.
Look at the trade off and figure out what works:
- Today - because you have to write it now, and have it work now, with what you have now.
- Next Week - because something will go sproing and will need to be fixed.
- Next Year - because what is needed changes overtime, and as such the solution will need to be revisited and updated.
- When You Die/Leave - Because you are not immortal, and will probably move onto something else sooner or later. At which point someone else has to be able to pick this up and work with it. Add those hand holds now.
Personally if nothing else is interacting with this API, why not implement it as a Library instead. Later, you can revisit the API question.
When you do revisit it, the library can be easily wrapped by some form of networked API, and the library interface can be stubbed with a proxy implementation to use the Networked API.