Building a REST API in Laravel

Question

I'm going from no-framework development to my first contact with Laravel (using version 5.1) and I'm a bit overwhelmed with the amount of stuffs to handle (migrations, seeds, hateoas, transformers, unit testing, error handling, etc).

I'd like to get some help at the return of the show method portion of it (following REST concepts). I have the following database structure:

companies -> users -> tickets -> interactions -> attachments

Now, when listing a specific ticket (like GET /customers/5/tickets/3), the screen needs to show all interactions for that ticket, along with all information in the ticket table (sort of like a page header) and the name of each user that created the specific interaction.

Thinking in terms of relationship, should I return all that data from the single call or should the information from the tickets table, for instance, be persisted in the front-end (from the index method call)? Even if I should persist the ticket information (header of the page), I am still left with interaction join users + N attachments for each interaction. What are the options to approach this?

I decided to open this thread because I was trying to Unit Test this call and I couldn't decide whether I should seed the database to have all the information necessary for it to work.

Edit

To better clarify my request, I'm not in doubt on how to handle the database communication, I already have my models set extending Eloquent class and I defined the hasMany, belongsTo, etc data.

namespace App\Models;

class Company extends Model {

    /**
     * Get the users from the company.
     * @return \Illuminate\Database\Eloquent\Relations\HasMany
     */
    public function users() {
        return $this->hasMany('App\Models\User');
    }
}

To not make the post bigger than it needs to be, I'll settle with just providing the Company model. I hope you all get the concept that I have Company, User, Ticket, Interaction and Attachment models all set and ready to use.

Edit 2

The question is around the practice in handling it. Should the GET /customers/5/tickets/3 return the ticket record, all interactions for it, the user for each interaction, all the attachments for each interactions? Isn't that over responsibility for a single endpoint? Like I mentioned above, I think I can demand from the front-end to persist the ticket information from when the front-end listed all tickets, that takes out the burden of the ticket record, but it's still a TicketController and there are still a lot of data to be loaded. I'm seeking for advice on handling this much information because I never did it before and I would like to minimize the amount of things I'll regret for doing.

Answer 1

I think you should return all the information your API consumers will need to display one ticket entry. I've worked on projects where there were query parameters to tell the server which related models to include, and others where subsequent AJAX calls were needed to get the associated data, but I think that's needlessly complex unless the interaction data is huge or very rarely needed.

I would recommend creating view partials for each model, so that you have flexibility in case one large view doesn't work out.

Solving the N+1 query problem you mentioned is trivial though. Here is a perfect situation for eager loading.

Try something like this: $tickets = Tickets::with('interactions','user')->get()

That will load all associated data in one query.