Usually, services call other services when they need to access their data. Each piece of data should belong to a particular service which will be the only entry point to accessing this data and modifying it. Some services will be simple and usually correspond closely to your domain model (e.g. a service for handling users) while others will be high-level and use data from other services (e.g. displaying a list of photos together with information about the users who uploaded them).
In your use case, you should start from the outside and think of what operations you want to make available to your user via an API (if it's a backend service) or what operations should be available in the GUI if it's a web application. Note that the GUI part is often a regular application with its own controllers: operations may be called via REST (like in AngularJS), but these endpoints are desinged only for the GUI application's use and are not microservices in the common sense.
Suppose you want to display photos together with information about uploaders. You could have a user service that returns information about a user given the user's ID and a photo service which can list photos (e.g. by searching by some criteria). The list of photos would contain for each photo the ID of the uploading user. This way these two services are not coupled - the photo service only knows about user IDs but nothing about the user data themselves. On top of these two services you could create a third service with an operation such as "list photos with information about uploaders" which would call the two other services and combine the data they return. Alternatively, this operation could be performed by your web application instead of a service.
