# Co-libry API

## Is the Co-libry API RESTfull?
### What is REST
REST stands for representational state transfer.
REST is a set of architectural constraints, not a protocol or a standard. API developers can implement REST in a variety of ways.
When a client request is made via a RESTful API, it transfers a representation of the state of the resource to the requester or endpoint.
### Criteria for RESTfull API's
For measuring if Co-libry's API is RESTfull we will compare it to the requirements described by Red Hat. https://www.redhat.com/en/topics/api/what-is-a-rest-api
#### 1.) Client-server
**Requirement**: A client-server architecture made up of clients, servers, and resources, with requests managed through HTTP.

**Response**: Co-libry's API follows a client-server archtitecture. Clients call the api with a certain request, the server handles the requests and calls upon it's resources to send a response. All requests are managed through HTTP.
#### 2.) Stateless
**Requirement**: Stateless client-server communication, meaning no client information is stored between get requests and each request is separate and unconnected.

**Response**: Co-libry's API uses stateless client-server communication. Each request from a client must contain all the information required by the server to carry out the request. The server cannot store information provided by the client in one request and use it in another request.
#### 3.) Cacheable
**Requirement**: Cacheable data that streamlines client-server interactions.

**Response**: Co-libry's API has caching for jwt keys and customer id's.
The server does not indicate to the client if requests can be cached or not.
#### 4.) Uniform interface
A uniform interface between components so that information is transferred in a standard form.
This requires that:
* **Requirement**: resources requested are identifiable and separate from the representations sent to the client.
**Response**: True, we use the URI standard to identify a resource.
* **Requirement**: resources can be manipulated by the client via the representation they receive because the representation contains enough information to do so.
**Response**: True, we use the HTTP standard to describe communication. For example, GET can be used to retrieve data about the URI-identified resource. You can describe an operation with an HTTP method and a URI.
* **Requirement**: self-descriptive messages returned to the client have enough information to describe how the client should process it.
**Response**: True, Co-libry's API consumes and produces standard MIME types like: application/json, application/x-www-form-urlencoded, multipart/form-data
* **Requirement**: hypertext/hypermedia is available, meaning that after accessing a resource the client should be able to use hyperlinks to find all other currently available actions they can take.
**Response**: False, Co-libry's API does not provide hyperlinks to currently available actions when accessing a resource.
#### 5.) Layered system
**Requirement**: A layered system that organizes each type of server (those responsible for security, load-balancing, etc.) involved the retrieval of requested information into hierarchies, invisible to the client.

**Response**: Co-libry's API works as a layered system. The requests are handled by a main entry point which can then in it's turn reroute the request to be handled by a different service invisible to the client. Data storage also happens on it's own servers (bigquery & elasticsearch)
#### 6.) Code on demand (optional)
**Requirement**: the ability to send executable code from the server to the client when requested, extending client functionality.

**Response**: Co-libry's API does not have the ability to send executable code from server to client.

### Conclusion
Going by these six requirements we can consider Co-libry's API RESTful for the most part. If we want it to be perfectly RESTful Hypermedia as the engine of application state (a.k.a. HATEOAS) and caching indication must be added. Code on demand to if you want to go all the way.