search

akvo / akvo-notifications

Turns business events into user notifications
GNU Affero General Public License v3.0
1 stars 1 forks source link

Build a draft of the REST API #3

Closed kardan closed 10 years ago

kardan commented 10 years ago

Since the notification service caters other internal services, these services are the users. To make sure we build a suitable service we should define the interface from which the notification service will be consumed.

Therefore we should define the REST API and it's resources. RAML might be worth investigating. In anyway the API definition should go into the product design document.

kardan commented 10 years ago

Among the things we need to review is how "service" v.s. "user" oriented the API should be. This ties into the fact that we don't yet have a single akvo-users collection but several per product.

/services/ /services/:id/ /services/users/ /services/users/:id/notifications/

v.s.

/services/ /services/:id/ /users/ /users/:id/notifications/services/:id/

There are of course a lot of variants of the example resources above, all with their pros & cons.

kardan commented 10 years ago

Implementation of the service & service-coll resources is somewhat set as an example. The two resources includes both a collection with (get & post) and a single service (get). Most other resources will probably only be using the get request method. Testing needs to be added. When we move forward writing tests should lead but since we didn't have a testing strategy that had to come afterwards.