[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Web services revisited

On 05/22/2012 07:06 PM, Chris Travers wrote:
On Tue, May 22, 2012 at 12:27 PM, John Locke<..hidden..>  wrote:

Possible Index handler:
GET /rest/1.0/my_company/ar_transactions/?invoice_id=N499216
I had a thought about this one.  Suppose we allow a by= field to
specify a non-standard id key?  In that case, your URL would look like

GET /rest/1.0/my_company/ar_transactions/N499216?by=invnumber

The desired result would then be to get a redirect to the the cannonical URL.

I am thinking that this avoids issues like:
GET /rest/1.0/my_company/customers/A1234/locations/billing?customers_by=meta_number&locations_by=location_class

In that case instead you'd do:

GET /rest/1.0/my_company/customers/A1234?by=meta_number

Capture the redirect address

then do

You could then either do a redirect and add the extension or pursue
the redirect with the content type header.

Note, by would only be valid where the field is a valid secondary key.
  The modules would be responsible for enforcing this.


Cool idea, but I'm not sure it's something I would actually use. On the client side, I need a unique key for each object -- that might as well be the same one as LSMB uses -- and I would rather have a single, canonical URL for each object.

So redirects to that are good, if they don't break other expectations.

And implementing a service, it's easy to assume either individual objects if I have what looks like a resource path (e.g. with an id) or collections otherwise.

So I would say this is fine, but not something high on my list or would likely use. It's just as easy to do an index lookup with the search parameters for other keys.

The biggest question I would have would be around the defaults. For example, on the AR transactions screen, a search by default only shows open invoices. However, a search by invoice number does return closed invoices even when the "closed" button is unchecked. This is a very nice feature for usability, but it's also somewhat unexpected. Should either document these exceptions very clearly, or remove them from the web service -- perhaps default to returning all invoices, and force a web service to specify open if that's all they want?

John Locke