How to design rest end point for an item having multiple types?

user_1216775 0
Viewed 82

I currently have some end points for notifications:

Create/Update: POST /notifications and params: SimpleNotif pojo

Get Notifs (listing): POST /notifications/query and params: NotifFilter pojo

Get Notif: GET /notifications/{id} and params: id of simple notif

Delete Notif: DELETE /notifications/{id} and params: id again

The NotifFilter pojo has fields like sortBy, offset, limit etc. Now notifications are of two types: simple and composite (aka summary). The above rest end points are used for simple notifications.

The POJOs SimpleNotif and SummaryNotif share lots of attributes as well. A summary notification will have all the same attributes (e.g. name, frequency etc.) along with a list of simple notifications. The summary notification can be triggered based on certain rules e.g. severity of one notification changes or multiple changes etc.

How to handle rest end point design for CRUD for the summary notifications ?

/notifications/summary

will conflict with 

/notifications/{id}.

The existing end points take a filter object for filtering, should I introduce type there? I don't think introducing a completely new rest end point is desirable as we already have one for notifications. Any suggestions how to handle CRUD for summarynotif?

Side Note: The reason for using POST for listing ( a GET actually) is URL length restriction in browser.

rest java
1 Answers

The existing end points take a filter object for filtering, should I introduce type there?

Yes, that would make sense with your current implementation, since considering the SummaryNotif is just a type of notification. So in future, if you introduce another type, you cannot just add another endpoint for it.

An alternate way of doing the same was introducing a query param ?type=summary(also for the fact that you're performing a GET under the name f POST), but since you already have a queryable endpoint, you shall reuse it with an additional parameter in your request object.

Another design suggestion would be that, you can create a parent (say Notification) out of SummaryNotif and SimpleNotif with esp. the attributes that are common to them, your basic CRUD could still look like :

Create/Update: POST /notifications and params: Accept a Notification object (subtyping helps here) 

Get Notifs (listing): POST /notifications/query and params: updated NotifFilter pojo

Get Notif: GET /notifications/{id} and params: id

Delete Notif: DELETE /notifications/{id} and params: id
user_17461180
Related