# Introduction
The Peaksolution B2C API is used to view, create, update and delete products that clients can purchase via the frontends like our PWA, Android App or iOS App.
On a higher architectural level the Peaksolution B2C API is compromised by a PHP object library that is independent from any framework like Magento. It mostly contains utility classes and business objects that are used for data exchange between the framework and the API/library. Those business objects are used for further decoupling of the model structure from the framework and thus increasing portability.
On the framework side the B2C API endpoints are represented by Magento controller classes with actions, some utility functions that ease the handling of responses and classes that transform Magento data into business objects and vice versa. This part needs to be changed/rewritten when the framework changes.
For each endpoint of the API a specification written as OpenAPI specification is available. It specifies parameters, models and responses for each endpoint. Additionally, for each endpoint there are exist API tests that are to be executed with Postman or with its CLI pendant newman and that can also be plugged into a CI system.
You can also check the JAMES Frontend (opens new window) to create a new user and check existing booking masks and API calls.
# Endpoints for accessing the data
The Peaksolution B2C API can be accessed via JAMES Proxy (opens new window) e.g. for /skipass/regions (opens new window)
A Swagger documentation is available at OpenAPI Documentation (opens new window)
The Middleware endpoint for authentication and user creation can be found at GraphQL Endpoint (opens new window)
# Description of HTTP status codes
Use meaningful HTTP status codes. Below is a list of possibilities with no claims of being exhaustive.
| Code | Description |
|---|---|
| 200 OK | use when successful and response contains content |
| 204 No Content | use when successful and no response content |
| 400 Bad Request | use when the request is syntactically incorrect e.g. body is not JSON |
| 401 Unauthorized | use when user not authenticated, but authentication needed |
| 404 Not Found | use when requested entity does not exist |
| 405 Bad Method | use when you e.g. expected POST but got GET |
| 409 Conflict | use when a entity like the one to be created already exists |
| 422 Unprocessable Entity | use when the request was syntactically correct but not semantically (e.g. missing required attribute) |
| 500 Internal Server Error | use when e.g. unhandled exception occurred |
# Description of HTTP methods
Use meaningful HTTP methods for API endpoints. Below is a list of possibilities with no claims of being exhaustive.
| Method | Description |
|---|---|
| GET | use when retrieving a resource |
| POST | use when creating a resource (or modifying data or state on the server) |
| PATCH | use when updating a resource (but not all parts of the resource need to be updated) |
| DELETE | use when removing a resource |
| PUT | use when updating a resource but all parts of the resource need to be updated |