0

I have a REST API. The fundamentals of the API takes care of two things.

  1. Authentication
  2. Routes

Let's say I was about to do a small service (microservice whatever...) next to the API and have it defined in it's own scope which could be a DLL or another service endpoint perhaps.

Then I would go back to the REST API and define a set of routes for interacting with that other small service (DLL or service endpoint).

Now, let's say that the other service needs to know about the authenticated user. Perhaps a user id, because it wants to return all the data inside that specific service. Should I just pass the user id to the service?

The above is just a small example of simple data that can be passed to another small service. But what if more than 2 services need to know about each other? That could be an email service that need to know whom has opened the email store that via another service because we need statistics. Etc.

How do I define and "make rules" around the boundaries of these different services?

Bear in mind that I want to keep this as stupid-simple as possible :)

  • 1
    It sounds like you don't have a REST API, but rather a number of services which are accessible from remote locations. Once you've made that distinction you can now start asking yourself questions about whether a service is stateful and what dependencies it has and how deeply it should have knowledge of "child services". IMHO I would go back and look at the design from the problem that you are trying to solve and not solve the problem from a specific design constraint. – jjrdk Oct 8 '14 at 8:39
  • So what you're saying is that instead of interacting with the underlying small services thorugh a REST API I should "just" interact with them as their own ? Still doesn't solve the how to overcome the boundaries of how much the single small service need to know about the other. – frostings Oct 8 '14 at 8:50
  • 3
    You haven't given any information as to what your options are for interacting with the other services. Can you do this in process? Do you want to make explicit boundaries, but have a shared authentication? Maybe you are better off publishing events from services which others can use without. This way you maintain a separation and leave it up to a service how it wishes to handle event data from other services. I would still advise you to consider what your requirements are before you jump to defining services. – jjrdk Oct 8 '14 at 9:00
  • It is not very clear what you mean by "overcome the boundaries". A single service should know as much as it needs to do its work, no more. If it needs the user id to do some service then it needs the user id to do some service. If it doesn't then why pass it to it? Maybe if you explained what you think the wrong way of doing this is it might become clearer as to what you are trying to avoid/solve. – Cormac Mulhall Oct 13 '14 at 8:50

Your Answer

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

Browse other questions tagged or ask your own question.