Is there a way to consume the api's without an actual http request ?

[Mina-R-Meshriky]

Something like the tests $this->jsonapi()->get('/api/v1/posts')
but to be used within the app, like maybe \JsonApi::server('v1')->get('api/v1/posts') which will return the json response content ?

[lindyhopchris]

Thanks for raising this. I definitely intended to do something like this to allow you to get JSON:API documents outside of a HTTP request, but didn't get round to adding it. It's just a matter of wiring up a few different parts of the package behind a fluent interface, and then documenting it.

[RaymondAtivie]

Really looking forward to this

[vrusua]

Useful feature, looking forward to getting this update as well.

[carlosjac]

This is exactly what I need!

[lindyhopchris]

Ok great, looks like a few people need this so will try to prioritise this.

Out of interest, are people expecting it to be authorised and validated? At the moment that's coupled to a HTTP request due to the way Laravel's form requests work. Or are you not expecting authorisation/validation?

FYI in a future version I'm going to have to decouple authorisation and validation from the HTTP request, so that we can support JSON:API Atomic Operations - but I'm not quite at that stage yet.

[carlosjac]

@lindyhopchris Thank you very much for paying attention to this request.

In my case, I don't need validation nor authorization because I'll use it from my controller which is already authorizated and validated.

Greetings

[bbprojectnet]

I'm also interesting that feature.

[lindyhopchris]

Yeah this is likely to be something I work on soon - as I need to decouple everything from HTTP requests to prepare for Atomic Operations, which I'm super excited to use (and is a feature that's been frequently requested!)

[bbprojectnet]

Yes, i'm also looking forward to atomic operations :)

[lindyhopchris]

In the linked testing issue (which isn't a problem with testing), the solution was to provide the server name to the facade when getting the resource container; however then you also needed to call withServer() on the resource class and give it the same server name.

If a container is derived from a particular server, it should either inject the server throughout whatever it creates, or at least inject the server name - so that any other server dependencies are derived from the same server as the container originated.

[tsterker]

We are currently also considering cases where it could be beneficial to do internal/programmatical API calls.

Use case: Single-sourcing the scoping (and attribute visibility etc.) rules of our laravel-json-api resources in a different context.

Example: You offer an API with somewhat involved scoping mechanisms (e.g. via indexQuery) and want to single-source that same logic in a different context such as a user dashboard written with Livewire to avoid "drift" in your scoping/access logic across your code base. By doing an internal API call, we could get that for free

Considerations: The API itself would also include middleware, policies and possibly some Server::serving logic etc. that is only executed in the context of an API call. So, one would need to understand such implications when leveraging internal API calls.

Here's a first draft of how such an internal API calls could be done:

$schema = JsonApi::server('v1')->schemas()->schemaFor('posts');

$posts = $schema->repository()->queryAll()
    ->filter(['draft' => 'true'])
    ->sort('-createdAt')
    ->with('attachments')
    ->get();

@lindyhopchris I would greatly appreciate your thoughts on the use case and the general approach we took in the above snippet. Do you see obvious flaws/pitfalls in the use-case or the way we are trying to do internal requests?