"musosdev" <(E-Mail Removed)> wrote in message
news:899FCC82-9484-408A-81DF-(E-Mail Removed)...
> Hi guys
>
> Bit of a generalist question, but I'm using ASP.net as my development
> platform.
>
> Basically, I have a website (an independent music store) and as well as
> the
> normal functionality, I'd like to build in an API, so that other sites
> (either asp.net or not) can query our data and get results back.
>
> Simple question... where do I start?! Can anyone point me in the direction
> of a "how to" (either technical or an overview of how an API should work).
> It's something I've not explored before, so I haven't a clue.
I find it useful to think about how the API will be used. In order to do
this, I use the UML Use Case diagram. I model one Actor shape for each kind
of entity that might want to access the API, then create use case shapes and
connect the actors to the use cases they use. As analysis continues, I find
common pieces of functionality that are shared amongst use cases. A login
function will be common between "update stock" and "list available music"
use cases. I connect these to the main use cases through Include connectors.
When I've done with this, I find a certain number of use cases that are
directly accessed by actors, and a certain number that are only used by
other use cases. The ones that are directly accessed by actors are your API.
In terms of a web service (which I recommend you create), these are the
operations in your contracts.
You may find sets of use cases that seem to belong together. For instance,
one actor may reference one set that the others never reference. This would
indicate you should split the functionality into two services, one for the
one actor and another for the others.
I don't know if that helps you, but it works for me.
--
John Saunders | MVP - Connected System Developer
|
Similar Threads
