The power of use cases is in describing conversations between an actor and a system. It is all about modelling the goals of the actors in interacting with the 'system'. The system may or may not involve a software solution. Use cases are solution agnostic for that reason. Go for approach 2. You need to start with modelling the functionality your actors require. Don't forget to think of all their functionality not what you think the system will do. I usually start from business process as a way of teasing out functionality.
If you start with thinking about web service clients and other solution considerations you're likely to miss essential business functionality. Stay away from the detail until you know the big picture.
What used to be called systems analysts are using use cases to define solution. I personally think they are a poor way of modelling solution. There are much better ways. But there is an overwhelming misuse of use cases out there. I feel like a lone round earther amongst a crowd of flat-earthers. One day they'll wake up :)
Kimbo
brought to you by enabling practitioners & organizations to achieve their goals using: