Specify Schemas
Specifying schemas with the help of generative AI
In programming, schemas are structures. These structures help define what is and is not allowed in a given call and response. Let's take a payment input form for example. Each field in the form has "structure" to it. For instance, names cannot have numbers, credit card numbers can not have alphabetical characters, expiration year cannot be in the past and must be a four digit integer.
Documentation and use of schemas in validation (a process that checks whether a given value matches a specified schema), provides a means of communication to users, developers, and systems.
In the case of the payment form, an API schema is used to let the client (a bicycle rental application for example) know what fields are expected for the payment request to go through . Client side validation on the user interface (credit card number input form for example) lets a user know that only 16 digit integers are accepted. Server side validation ensures that just because a user does not the use specified payment form, for the server to only accept requests if they align to a particular schema.
Example: Creating a schema for a credit card form
Prompt
Response
Sure! Here's an example of how you can create a schema for a credit card form to be used on the client side in a Next.js Chakra UI app:
In this schema, we're using the Yup library to define a schema for a credit card form with the following fields: name, cardNumber, expirationMonth, expirationYear, and cvv.
The name
field is a string that is required and must match the regular expression /^[a-zA-Z\s]*$/
to ensure that it only contains letters and spaces.
The cardNumber
field is a string that is required and must match the regular expression /^[0-9]{16}$/
to ensure that it only contains 16 numeric digits.
The expirationMonth
field is a number that is required and must be between 1 and 12.
The expirationYear
field is a number that is required and must be in the future and within the next 10 years.
The cvv
field is a string that is required and must match the regular expression /^[0-9]{3}$/
to ensure that it only contains 3 numeric digits.
You can use this schema to validate the input data on the client side before submitting it to the server. For example, you can use the validate
function from Yup to validate the form data against the schema, like this:
In this example, we're using Chakra UI's FormControl, FormErrorMessage, FormLabel, and Input components to create a form that includes the fields defined in the credit card schema. We're also using the useFormik hook from formik to manage the form state and handle form submission.
We're passing the credit card schema to the validationSchema
prop of the useFormik hook to validate the form data against the schema. The isInvalid
prop of the FormControl component is set to true
if the field has been touched and there is a validation error.
Finally, we're using the getFieldProps
function from formik to bind each form input to the corresponding formik field, and using the handleSubmit
function from formik to handle form submission.
That's it! You can use this credit card form component in any other React component in your Next.js app.
Discussion
In the response from ChatGPT, we can see the code provided uses a library called Yup and Formik to specify the schema and then apply that schema to the form.
Example: Specifying a credit card OpenAPI Spec
OpenAPI spec's are the industry standard for documenting an API service. An API service is a application hosted on a server that accepts requests from the web and returns responses. These specifications help systems and developers understand what data and thieir types are expected to be sent to receive an expected response.
Prompt
Response
In this OpenAPI spec, we're defining a POST
operation for submitting credit card information to the /credit-card
endpoint. The operation expects a JSON object in the request body with the following fields: name
, cardNumber
, expirationMonth
, expirationYear
, and cvv
. We're using the CreditCardInput
schema to define the structure of the request body, which includes the required fields and their data types, minimum and maximum lengths, and minimum and maximum values.
We're also defining two possible responses: a successful 200
response and an error 400
response that includes an array of error messages if the input data is invalid.
Finally, we're defining the OpenAPI spec components, including the CreditCardInput
schema, which can be reused in other endpoints or operations.
Note that this OpenAPI spec is just an example, and you may need to adjust it based on your specific use case and requirements.
Last updated