Standard end points and reuse of Web APIs

[marcoscaceres]

Following up on the discussion on twitter, the problem is that the proposal replicates functionality that one can create using already-standardized web technologies. As you argue in the README, on their own, the programming primitives are not straight forward to use (XHR, CORS, etc.); however, once a library is written to implement the API you are proposing, and the search providers agree to enable CORS for the JSON file, that becomes essentially a solved problem (without any additional help from a UA).

I would strongly urge you to build a JS library and consensus amongst interested parties. That will still allow for standardization of things like the JSON file location, while allowing the API to grow and adapt organically to the needs of search providers. It will also allow you to build more flexibility into, for instance, pagination and specific search filtering parameters.

For more rationale on why browser vendors prefer to only work on low-level APIs, please see: https://extensiblewebmanifesto.org/

[csuwildcat]

@marcoscaceres I totally understand the position, but there are some aspects that are difficult to do without the UA eventually standardizing an interface with inferred permissions:

• Caching and timeout of the services.json endpoints is difficult to do with transient, client-side code.
• Auto-allowance of CORS via the origin's explicit inclusion in the services.json would be a huge plus
• Other services that will follow have much greater dependencies on the UA, consider the following: Once we have a standard data consumption search model and semantic object results, the UA could create a unified, standard Cart API that products can be seamlessly processed through regardless of the site you're purchasing from

This is just phase 1 of what could be a really important step for the web: understanding the consumer flow and being a part of it. If we can't get support in the UA for this, we'll try the best we can, but I'm guessing the reach and volume of the initiative will be muted without it :/

[csuwildcat]

@marcoscaceres one comment on this "For more rationale on why browser vendors prefer to only work on low-level APIs, please see: https://extensiblewebmanifesto.org/"

I know Brian Kardell and the rest of the folks who create the Extensible Web Manifesto, and the idea was that we shouldn't jump to high-level abstractions first without making the low-level hooks available, but it doesn't mean that we can't assemble high-level abstractions where they make a common developer use-case much easier.

As I said, I totally understand your position, and definitely respect any UAs who choose not to work with us toward these goals - I just hope they do in the end :)