I currently have some end points for notifications:
Create/Update:
POST /notifications
and params:SimpleNotif
pojoGet Notifs (listing):
POST /notifications/query
and params:NotifFilter
pojoGet Notif:
GET /notifications/{id}
and params:id
of simple notifDelete 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 (eg name, frequency etc.) along with a list of simple notifications. The summary notification can be triggered based on certain rules eg 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.
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
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.