Frameworks usually grow from necessity and with maturation. This lead to diversity not only in their design but also in the features they provide to developers. In this section are gathered most of these features:
• HTTP I/O. Management of HTTP messages from parsing and request encapsulation to rendering, following the protocol. Normally provided through transparent interfaces that underneath handle concurrency and distribution.
• Data storage. Allow easy connections to databases. First abstractions were very simple and required developers to write SQL queries like the PDO class in PHP [Gro]. Some frameworks abstract queries through functions enabling reuse across different databases, like the Schema class in the Laravel framework [Otwb]. More recently object-relational mapping (ORM)1 has been adopted once enables flexibility to change of models, as in the ASP.NET Entity Framework [Mic].
• Routing. Mapping of the requests’ URIs and HTTP methods to actionable code through pattern matching. This process may include parameters extraction and validation as shown in Source3.1.
1 Route::get(’user/{id}/{name}’, function($id, $name)
2 {
3 //
4 })
5 ->where([’id’ => ’[0-9]+’, ’name’ => ’[a-z]+’])
Source 3.1: Example of routing with the Laravel framework [Otwa]
• Serialization. Used to encapsulate requests information into objects or extract responses information from objects. The use of objects is usually related with the fact that they have a higher degree of semantics. Implementations allow structuring, exclusion and inclusion of information, or even transformation when dealing with composed data.
• Parsing & Rendering. Extraction of structured data from requests bodies (parsing) and creation of response bodies from structured data (rendering). Parsers and renderers are used accordingly with the media-types in the Content-Type or the Accept headers (section2.6.2).
The application/xml and the application/json media-types are the most commonly imple-mented. Some implementations also apply serialization for performance reasons.
• Filtering. Clients often implement search functionalities over collections of resources.
When the search involves resource fields is created one service that accepts query param-eters that filter the base result (e.g. /products?isAvailable=true). For searches that also involve other resources another service should be created that comprises distinct logic (e.g. /categories/{categoryId}/products). Filtering may be provided at the data management level or at the service level.
1Maps the state and actions of objects to database columns and queries, respectively.
• Sorting. In spite of representing an additional overhead on requests and being supported by data management, sorting may be provided if requested through query parameters. These parameters may be the field to order by or the sorting direction.
• Pagination. Some collections of resources tend to grow over time, being hard to represent in client applications. Pagination helps solve this problem as it also reduces latency. This feature has the page size or the page number as parameters that can be omitted, the first when the value is constant and the second to retrieve the first page.
• Projection. Different client applications may have different information needs. Instead of implementing different services that return more or less information, requests may indicate what information is needed or not. This feature is not very frequent.
• Validation. In order to guarantee consistency of data and prevent malicious usage frame-works allow requests to be validated. This goes from preventing that no two users have the same email, guaranteeing that an email field follows the right format, a number field is inside some range, etc.
• HATEOAS. Web services to be compliant with REST should use hypermedia as the engine of application state. This means that returned representations include links to related re-sources. Frameworks are capable until some extent to incorporate these links in responses, for example when using pagination by including the link to the previous and next page.
• Authentication. The authentication schemes supported by HTTP (section 2.6.5) are nor-mally implemented by frameworks, requiring only to be plugged and characterized. When authentication is used, services may refer to an object of type user that represents the re-quester.
• Authorization. Access to services can be restricted to groups of users. By defining which users can access to which services, frameworks are capable of handling non-authorized requests without the service code even being called.
• Conditional requests. As specified in section 2.6.3, to implement conditional requests, responses must include the E-Tag or the Last-Modified headers and requests conditions must be verified and answered accordingly.
• Rate limiting. For preventing abuses in the use of web services, some restrict the amount of requests a user can do during a period of time.
• Caching. Is one of the REST constraints (section 2.5) and is supported by HTTP (sec-tion2.6.4) in a way that can be abstracted by frameworks.
• Content negotiation. Web services may return representations using a predefined media type without obeying to the Accept header. The process to choose the used media type is called content negotiation and some frameworks provide a set of possible approaches.
• HTTP method override. Allows clients to use a HTTP method to call a service that is provided by another HTTP method, using the X-HTTP-Method-Override header. Normally is used by browsers that don’t support the PATCH method.
• Cross-origin resource sharing. Most browsers impose the same-origin security policy what obliges web services to implement CORS [W3C14].
• Testing. In order to validate development and prepare deployment, frameworks may provide an interface for testing services without the need to have client applications implemented or real users.
• Logging. During development or even the production phase it is normal the occurrence of errors in services. To better identify and quickly solve any bugs, information about the en-vironment in which those errors occurred is crucial. Frameworks can keep this information through requests’ logging.
• Documentation. Web services consumers rely mostly in documentation to easily under-stand capabilities and how to explore them. This means that is important to have the imple-mentation synchronized with docuimple-mentation. Most frameworks give the means for this to happen.
• Versioning. It is useful for evolving APIs without having to manually change routing for each service.