Specification
This document adheres to RFC2119
General
the API must be a GraphQL API as specified
entrypoint must be
/graphql/
HTTP response status code must be
200
use OXID models and create DataTypes as facades for GraphQLite
relations to other DataTypes should be nullable (and return null in case the requested object is not accessible or not existend)
Login/Auth
auth against the API must be done via a Bearer JWT in the
Authorization
HTTP headerthe
token
query must not have a token sent with the HTTP request
Naming
Queries
must not have
get
orhas
or similar prefixquery name must be singular or plural object name
- valid examples:
user
users
product
products
- invalid examples
getUser
fetchProduct
must have proper input type definitions
Queries for lists
Additional to the rules applied for the queries, when querying for lists the query should have the following input parameters - all optional.
filter
which should be of typeObjectFilterInput
(which you have to create and name accordingly)the fields of this
FilterInput
type should be of one of the provided filter input types
sort
which should be of typeObjectSorting
(which you have to create and name accordingly)limit
which must be of typeInt
(if ommitted must behave as no limit)offset
which must be of typeInt
(if ommitted must behave as 0)
Mutations
must start with the object name, then the action verb (camelCase)
- valid examples
userRegister
categoryCreate
categoryUpdate
categoryDelete
- invalid
createuser
should not use generics (create, update, delete), but the correct domain verbs where possible (register user vs. create / add, place order vs. create, …)
must have proper input type definitions
Fields
every field from every model should be available as a GraphQL field and must have a correct type annotation (
ID
foroxid
database field, notString
)multilanguage fields must not be exposed separately, but in context of the language of the token as a normal field (no
title_1
ortitle_2
fields, onlytitle
for theoxarticles.oxtitle\*
database fields)parent ids, object ids, foreign keys (relations), etc. must be exposed via their correct type
example: a product has an
oxvendorid
, which should not be exposed asID
orString
field, but as a relation to that specific typeyou may additionally add the field with the
ID
type when necessary
type Product {
# do
category: Category!
# don't
categoryId: ID!
}