RESTful URLs for multiple resource in the same Microservice

Question

We are developing a serverless application (AWS API Gateway, Lambda, and Dynamo) keeping users and groups in the same microservice as they are being stored in the same DynamoDB table. REST endpoints for the users look like this:

/user/invites
/user/:userId/save
/user/:userId/activate

Is the a good idea to have endpoints for groups look like:

/groups/
/groups/add/
groups/:groupId/remove
/group/:groupId/addUser/:userId

Is it okay to have endpoints with different "base" in the same microservice?

Answer 1

No, its a pain in the arse to parse the ids out of the string afterwards. Which you often want to do for logging or routing.

Try and keep the depth and the syntax of your Urls constant

groups/get/{id}
groups/add/{id}
groups/remove/{id}
groups/adduser/{id}/{userId}
users/add/{id}

Now I have a pattern which will match everything

{type}/{operation}/{typeId}/{extra stuff}

I wont have to write a regex or code which goes:

if(firstPathNode == "group" and secondPathNode != "add","remove", "invites")
{
    typeId = secondPathNode
}

and I'll never have to write

if(userId =="add")
{
   throw new Exception("you cant use that Id because it conflicts with a route")
}

Answer 2

We are developing a serverless application (AWS API Gateway, Lambda, and Dynamo) keeping users and groups in the same microservice as they are being stored in the same DynamoDB table.

Is it okay to have endpoints with different "base" in the same microservice?

From the perspective of REST: yes, of course. An important idea in REST is that we have a common understanding of the semantics of our self descriptive messages, but we have freedom in how we handle those messages.

So REST isn't going to care if the representations of those resources are generated by a single function, or by multiple functions. And REST isn't going to care, in the case of multiple functions, whether they are released together or separately, whether they are implemented by the same team or different teams, and so on.

---

Clearly the implementations of your resources have some coupling, because they are sharing the same Dynamodb table, so your current design cannot handle schema changes that contradict each other. Any change to your stored schema that requires a backwards breaking change will necessarily require coordinating the release of changes for both resources.

But there's no particular reason that all of your request handlers need to be implemented using the same lambda runtime.

What you've really got are a number of trade offs, and the best choices to make are going to depend on local circumstances (which may be changing over time).

But absolutely: one of the possibilities is that all of the resources under /user and all of the resources under /group belong in the same "microservice".

Answer 3

Having endpoints within a single microservice with a different base is going to extremely complicate stuff for you later on. A thing which is not that apparent at the moment, with a single microservice, but will quickly become apparent once the count of your microservices grows.

Imagine you're running 20 microservices, one for each separate context. Integrating 20 microservices by a client is a complete no-go. So what do you do instead? You setup a service discovery, each microservice registering itself into it upon deployment, and the frontend for all your microservices being an API Gateway, talking to the discovery service handling the routing to respective microservice instances. This way the client may integrate a single hostname, having all microservice available to them, without needing to remember 20 different targets.

But you come across a problem. You want to be able to easily configure the API Gateway, routing the FE request to an appropriate microservice based on the URL prefix. This is not possible to do out of the box, if you have different bases for a single microservice, you will need to introduce some form of rerouting:

• when FE base is groups, pass it to user-management-service microservice,
• when FE base is users, pass it to user-management-service microservice.

But then situation complicates even further. You introduce a second microservice which also supports groups. And you also model the groups as a base. Now how are you going to distinguish that on the API Gateway level? You need to introduce a mechanism to do so, so you prefix your current endpoints by a unifying base, changing your API Gateway configuration:

• when FE base is user-management, pass it to user-management-service microservice,
• when FE base is car-management, pass it to car-management-service.

If you define base for a microservice based on its context right out of the box, it will make your potential routing in the future thousands times easier.