Merge pull request #253 from jumpjack/patch-1

fixed typos/formatting
This commit is contained in:
Florian BEZANNIER
2021-10-23 15:32:55 +02:00
committed by GitHub
+15 -1
View File
@@ -1,5 +1,19 @@
# psa-connectedcar
*PSA B2C Connected Car API* # Introduction This is the description of the *Groupe PSA Connected Car V2 API*. The speccification is is based on **OpenAPI Specification version 3** and can be displayed via [ReDoc](https://github.com/Rebilly/ReDoc)a or [Swagger](http://swagger.io). This API allows applications to fetch data from the connected Vehicles data platform. # Authentication PSA Connected Car APIs uses the [OAuth 2.0](https://tools.ietf.org/html/rfc6749) protocol for authentication and Authorization. any application require a valid [Access Token](https://tools.ietf.org/html/rfc6749#section-1.4) to access to user data. # Errors Error codes returned by all REST APIs comply with the standard. Nevertheless, PSA Services (callers) need to have more complete data structures (even when the answer is not Http-OK) to better detail the type of error by providing application code, message and a debugging code(for investigation purposes). The http code of the response is managed by the protocol itself (in the header). **Errors are returned as a generic error response:** * ```xError``` object model.
*PSA B2C Connected Car API*
# Introduction
This is the description of the *Groupe PSA Connected Car V2 API*. The speccification is is based on **OpenAPI Specification version 3** and can be displayed via [ReDoc](https://github.com/Rebilly/ReDoc)a or [Swagger](http://swagger.io).
This API allows applications to fetch data from the connected Vehicles data platform.
# Authentication
PSA Connected Car APIs uses the [OAuth 2.0](https://tools.ietf.org/html/rfc6749) protocol for authentication and Authorization. any application require a valid [Access Token](https://tools.ietf.org/html/rfc6749#section-1.4) to access to user data.
# Errors
Error codes returned by all REST APIs comply with the standard. Nevertheless, PSA Services (callers) need to have more complete data structures (even when the answer is not Http-OK) to better detail the type of error by providing application code, message and a debugging code(for investigation purposes). The http code of the response is managed by the protocol itself (in the header).
**Errors are returned as a generic error response:**
* ```xError``` object model.
This Python package is automatically generated by the [Swagger Codegen](https://github.com/swagger-api/swagger-codegen) project: