L10n:Pontoon/API: Difference between revisions
Jump to navigation
Jump to search
(Created page with "''For now, this page serves as a scratchpad for documenting the research into different API solutions for Pontoon. Once one solution is chosen and implemented, this page will...") |
No edit summary |
||
| Line 5: | Line 5: | ||
* Stats for a locale: supported projects, status of each project. | * Stats for a locale: supported projects, status of each project. | ||
* Stats for a project: supported locales, incomplete locales, complete locales. | * Stats for a project: supported locales, incomplete locales, complete locales. | ||
We'll be considering three solutions: REST, GraphQL and GraphQL with Relay. | |||
==REST== | |||
REST has been the ''de facto'' standard of API design for the last 10-15 years. | |||
====Pros==== | |||
* Easy to implement thanks to the [http://www.django-rest-framework.org/ Django REST Framework] project | |||
* Browsable API: http://restframework.herokuapp.com/ | |||
* Familiar to the consumers of the API | |||
* The developer has the exact control over which fields and relations are exposed | |||
====Cons==== | |||
* By default, all fields as decided by the developer, are exposed and transferred, resulting in increased bandwidth | |||
** Work-arounds exists, e.g. &fields=foo,bar | |||
* Only the relations expected by the developer can be queried in a single query, e.g. `project/1/locales` | |||
** Other relations require multiple requests, which can't be optimized | |||
* Requires versioning and documentation | |||
Revision as of 15:38, 11 July 2017
For now, this page serves as a scratchpad for documenting the research into different API solutions for Pontoon. Once one solution is chosen and implemented, this page will feature the documentation about this solution.
In Q3 2017, we'd like to make some data stored in Pontoon openly available for third-parties. The main driver is the use case from bug 1302053:
* Stats for a locale: supported projects, status of each project. * Stats for a project: supported locales, incomplete locales, complete locales.
We'll be considering three solutions: REST, GraphQL and GraphQL with Relay.
REST
REST has been the de facto standard of API design for the last 10-15 years.
Pros
- Easy to implement thanks to the Django REST Framework project
- Browsable API: http://restframework.herokuapp.com/
- Familiar to the consumers of the API
- The developer has the exact control over which fields and relations are exposed
Cons
- By default, all fields as decided by the developer, are exposed and transferred, resulting in increased bandwidth
- Work-arounds exists, e.g. &fields=foo,bar
- Only the relations expected by the developer can be queried in a single query, e.g. `project/1/locales`
- Other relations require multiple requests, which can't be optimized
- Requires versioning and documentation