[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Web Services API: URL naming proposal
- Subject: Re: Web Services API: URL naming proposal
- From: Chris Travers <..hidden..>
- Date: Fri, 18 Nov 2011 05:52:20 -0800
Figure i will wade in here. Hopefully others will follow.
On Sun, Nov 13, 2011 at 10:45 AM, Erik Huelsmann <..hidden..> wrote:
> Hi all,
> Before going into detail how to interact with resources, I think we
> need to come up with a resource (URL) naming scheme which works for
> our application. There may be some things to consider, so, I thought
> I'd put out a proposal for review. From there, we could go into the
> more technical details of the actual interaction.
> We agreed to start with the functionality which has been rewritten
> since our SQL Ledger fork, known as 'new code'. One of the notable
> areas this has happened to is the way customers, vendors and employees
> are now recorded. I'll direct my proposal there first.
That's probably wise since other web services would habe to be rewritten later.
> Before going into the details of the customer/vendor store, there are
> a few general subjects to address:
> 1. The base address mentioned by John was something like
> 'http://myledger.com/ledgersmb/store/'. However, if we assume that the
> login address of the 'http://myledger.com/ledgersmb/login.pl', there
> may be an issue with the '/store/' part. Can we support that on all
> servers, or does that not matter? Do we allow '/store.pl/' or any
> other URL? ie. do we not consider that part of the API, other than
> that it is a prefix?
i don;t think that would be a problem. I don't like store though
because it is pretty unclear. I would suggest a base path of:
Then http auth headers can be used for the rest.
> 2. Since companies are separate databases, where do we put the name of
> the company in the URL? <prefix>/store.pl/<company>/<etc...>?
What do you think of the above proposal?
> Are there other items to consider before we go to specify the web
> service behaviour of our natural/legal entity storage paradigm?
I think the key issue is designing a logical entity hierarchy for
things. Otherwise I don't see any other issues that will come up in
this preliminary stage.