# API Standards for Foundation Services

In creating and maintaining the public-facing structure of a foundation service,
you should hold yourself to several first-order goals:

* The purpose of the service should be readily apparent.
* The supported usage models of the service should be easy for a new
  consumer to understand.
* The service should be consistent with other foundation services.
* From the API documentation and tests, it should be feasible
  to develop a distinct implementation of the service (i.e., without having to
  delve into the internals of the current implementation).

Below we outline concrete standards that aid in achieving the above goals.

## Naming

* Strive to give your service a name that makes it immediately obvious what the
  service is for ("network", "metrics").

* Avoid the usage of "Service" in interface names. While the term "Service" is
  overloaded in Chromium, in the context of //services it has a very specific
  meaning and should not be overloaded.

* Strive to avoid conceptual layering violations in naming -- e.g., references
  to Blink or //content.

* Use the names "FooClient" and "FooObserver" consistently in interfaces. If
  there is an expected 1:1 correspondence between Foo and its counterpart, that
  counterpart should be called FooClient. If there is an expected 1:many
  correspondence between Foo and its counterparts, those counterparts should be
  called FooObservers.

## Documentation

* Every service should have a top-level README.md that explains the purpose and
  supported usage models of the service.

* Every public interface should be documented at the interface (class) level and
  at the method level.

* Interface documentation should be complete enough to serve as test
  specifications. If the method returns information of a user's accounts, what
  happens if the user is not signed in? If the method makes a request for an
  access token, what happens if a client makes a second method call before a
  first one has completed? If the method returns a nullable object, under which
  conditions will it be null?

* Strive to avoid your documentation being too specific to a given client.

## API Shape

* Strive to avoid molding your API shape too specifically to the needs of a
  given client. Most foundational services should make sense even in a
  Chrome-less system environment. A good test is: Would your service's APIs seem
  sensible to users who don't have knowledge of Chrome's specific needs?

* If a given interface Foo requires "construction parameters" (e.g., the client
  must give it a FooClient before calling any methods), provide a FooProvider
  interface with a GetFoo() method that takes in the relevant construction
  parameters. This approach eliminates the possibility of a badly-written (or
  malevolent) client calling methods on a partially-constructed Foo. To be
  concrete:

    ````
    // NO: Client will have access to partially-constructed Foo.
    interface Foo {
      SetClient(FooClient client);
      ...
    };

    // YES: Foo will be completely constructed before client has access.
    interface FooProvider {
      GetFoo(Foo& request, FooClient client);
    };
    interface Foo { ... };
    ````

* In the absence of specific guidance, strive for consistency with surrounding
  interfaces and with interfaces in other services.

## Testing

* Use service tests to test the public interfaces exposed by your service.

* Every public method should be covered by at least one service test. Strive
  to have your tests enforce your documentation (corollary: if you can enforce
  your documentation without any tests, improve your documentation :).

* Think of these tests as a form of "compliance tests": They should be written
  in such a way that engineers with a distinct implementation of your
  APIs should trivially be able to run your tests against their implementation.
  Notably, try to avoid relying on implementation details of the service in its
  tests.

* Related to the above, aim for a high degree of coverage with these tests. If a
  reimplementation passes your tests, you should have a high degree of
  confidence that it will be usable by your consumers.

## Appendix: Responsibility for Upholding These Standards

The responsibility for holding these standards is shared across
//services/OWNERS, individual service OWNERS, and services developers:

* //services/OWNERS own the standards themselves and are responsible for
  ensuring that quality and consistency are maintained across //services.
* Individual service OWNERS are responsible for ensuring that their service
  adheres to these standards.
* Service developers are responsible for ensuring that their CLs adhere to
  these standards (and thus making life easier for the OWNERS that must review
  these CLs :).

We expect that these standards will evolve over time. If you encounter a tricky
situation not covered here, please send an email to services-dev@. Similarly, if
you see inconsistency or violations of the standards, please file a bug and CC
relevant OWNERS (i.e., of the service in question and/or //services/OWNERS).