Verizon APis are implemented as lightweight, fast, scaleable , secure and easy to maintain RESTful services. We adhere to the KISS (Keep it Simple and Straightforward) principle to make our APIs easier to consume with a simple syntax and semantics.
We also document our APIs thoroughly as we believe that a good API lives by its documentation. We use Swagger tool for our API documentation.
The following are the general desgin guidelines that our developers adhere to for the API standards
Statelessness – This is one of the REST constraints, to achieve or adopt this constraints there’s one place you dona’t want your API to be storing state, and that’s in your application servers. Always keep application servers state-free so that they can be easily and painlessly scaled. In almost all cases a REST API should be entirely stateless. As part of processing it is possible for an API to gather context and pass this to a downstream system, however an API should not maintain that context for future requests.
Content Negotiation – We use content negotiation (eg. Accept headers), or differing URLs for different representations (eg.? format=json), or a combination of both to support multiple representations of our resources
URI Templates – URI Templates are a well-defined mechanism for providing URL composition capabilities to our clients, or for documenting our URL access patterns to your end-user.
Error Logging – We implement advanced error logging in order to identify and trouble shoot issues quickly and for security purposes..
Pagination – Pagination serves two big purposes in an API; it reduces the amount of unneeded data delivered to the client, and it reduces the amount of unneeded computation on your application servers.
When designing and developing an API it is important to consider the representation of that API. This commonly includes an interface specification that fully describes the API. To ensure the success of an API it should be easy to consume driving a well-considered representation layer.