<commit_before>---
description: Application Implementation for the Server + API architecture scenario
toc: true
topics:
    - architecture
    - server-apps
    - api-auth
    - authorization-code
    - client-credentials
contentType: tutorial
useCase:
  - invoke-api
  - secure-an-api
  - build-an-app
---

# Server + API: Application Implementation

In this section of the tutorial, we will take an in-depth look into our API and its associated Machine to Machine Application.

::: note
  For simplicity reasons we will keep our implementation solely focused on the authentication and authorization part. As you will see in the samples the input timesheet entry will be hard-coded and the API will not persist the timesheet entry, simply echo back some of the info.
:::

## Define the API endpoints

First we need to define the endpoints of our API.

::: panel What is an API endpoint?
An **API endpoint** is a unique URL that represents an object. In order to interact with this object you need to point your application towards that URL. For example, if you had an API that could return either order or customers, you might configure two endpoints: `/orders` and `/customers`. Your application would interact with these endpoints using different HTTP methods, for example `POST /orders` to create a new order, or `GET /orders` to retrieve the dataset of one or more orders.
:::

We will configure one single endpoint that will be used for creating timesheet entries. The endpoint will be `/timesheets/upload` and the HTTP method `POST`.

The API will expect a JSON object as input, containing the timesheet information. We will use the following JSON:

```json
{
  'user_id': '007',
  'date': '2017-05-10T17:40:20.095Z',
  'project': 'StoreZero',
  'hours': 5
}
```

The API will print the JSON, so we can verify the contents and echo back a message like the following: `Created timesheet 14 for employee 007`.<commit_msg>Making order plural for consistency<commit_after>---
description: Application Implementation for the Server + API architecture scenario
toc: true
topics:
    - architecture
    - server-apps
    - api-auth
    - authorization-code
    - client-credentials
contentType: tutorial
useCase:
  - invoke-api
  - secure-an-api
  - build-an-app
---

# Server + API: Application Implementation

In this section of the tutorial, we will take an in-depth look into our API and its associated Machine to Machine Application.

::: note
  For simplicity reasons we will keep our implementation solely focused on the authentication and authorization part. As you will see in the samples the input timesheet entry will be hard-coded and the API will not persist the timesheet entry, simply echo back some of the info.
:::

## Define the API endpoints

First we need to define the endpoints of our API.

::: panel What is an API endpoint?
An **API endpoint** is a unique URL that represents an object. In order to interact with this object you need to point your application towards that URL. For example, if you had an API that could return either orders or customers, you might configure two endpoints: `/orders` and `/customers`. Your application would interact with these endpoints using different HTTP methods, for example `POST /orders` to create a new order, or `GET /orders` to retrieve the dataset of one or more orders.
:::

We will configure one single endpoint that will be used for creating timesheet entries. The endpoint will be `/timesheets/upload` and the HTTP method `POST`.

The API will expect a JSON object as input, containing the timesheet information. We will use the following JSON:

```json
{
  'user_id': '007',
  'date': '2017-05-10T17:40:20.095Z',
  'project': 'StoreZero',
  'hours': 5
}
```

The API will print the JSON, so we can verify the contents and echo back a message like the following: `Created timesheet 14 for employee 007`.
{'fraction_non_alphanumeric': 0.06864516129032258, 'fraction_numerical': 0.013419354838709678, 'mean_word_length': 3.975609756097561, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7386397', 'n_tokens_mistral': 1032, 'n_tokens_neox': 966, 'n_words': 555}