1

I've created an API server using Laravel and set up FormRequests to handle incoming requests to the server. It all worked well. Now I'm trying to switch my API server to follow https://jsonapi.org/ specification, and I have no clue how to switch validation to handle complex incoming (POST, PUT, PATCH) JSON structure.

The only solution that I found working is to use in each FormRequest extended class, rules, following the pattern shown in the code block.

/**
 * Get the validation rules that apply to the request.
 */
public function rules(): array
{
    return [
        'data' => 'required',
        'data.type' => 'required|string',
        'data.id' => 'sometimes|required|string',
        'data.attributes' => 'sometimes|required',
        'data.attributes.name' => 'string',
        // ...
    ];
}

/**
 * Get data to be validated from the request.
 */
protected function validationData(): array
{
    return $this->json()->all();
}

The solution I came up with does the job, but I'm looking for a more DRY solution since this solution gets very messy if I'm validating more complex and nested JSON structure.

  • if you didn't already then you can try this : [Laravel: validate json object](https://stackoverflow.com/q/44001030/2794280) – kgzdev Mar 29 '19 at 08:29
  • I'd think the recommendation would be to use a validation library that supports JSON:API (out of curiosity why JSON:API and not OpenApi ?) . In the implementations there's [Art4/sjon-api-client](https://github.com/Art4/json-api-client) which claims to perform validation so perhaps you can try integrating that in laravel. – apokryfos Mar 29 '19 at 08:44
  • @ikram Extracting JSON payload from the request is done within the "validationData" function. At this moment I am basically doing like the answer from the mentioned post. Thanks for the answer, I appreciate it. – Stefan Lazarević Mar 29 '19 at 08:51
  • @apokryfos Why I chose JSON:API over OpenAPI is because on work, I've never needed to implement json standard to the api, all of them were non starndardized REST API's so I decided to do so on the internal project for the practice. JSON:API was the first one that pop up when I searched for standards, and after reading documentation I liked it so I decided to give a shot. Implementation of responses wasn't dificult, but after I finished with it, I got stuck with request validation. – Stefan Lazarević Mar 29 '19 at 08:56
  • @apokryfos Since I am not familiar with OpenAPI yet, and I will need some time to read the documentation, can you tell me from your opinion, what do you find as pros and cons of using OpenAPI? – Stefan Lazarević Mar 29 '19 at 08:57
  • The reason I asked is because I'm (coincidentally) at a similar decision making point in one of our projects. I've used OpenAPI for something very simple and basic before but I only did it because at the time that (or rather Swagger) was the first thing to pop up in search results. If you want an in depth analysis of pros and cons then you're not alone. – apokryfos Mar 29 '19 at 08:59
  • @apokryfos Using a library is an option, what I wanted to explore is if there is some solution that does not require exploring and integrating additional library. What I came up as an option is to maybe integrate JSON Schema validation instead of FormRequest, but I still need to analyze how many changes that will require. – Stefan Lazarević Mar 29 '19 at 09:01
  • 2
    @apokryfos you don't need to choose between JSON:API and OpenAPI, the former is a specification for your API responses format, and the latter is an API description and documentation tool. You can basically document your JSON:API api with OpenAPI. See this post for more info https://apisyouwonthate.com/blog/json-api-openapi-and-json-schema-working-in-harmony – osteel Nov 26 '19 at 19:52

0 Answers0