Closed kardan closed 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.
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.
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.