Support the ongoing development of Laravel.io →
posted 9 years ago
Architecture
Last updated 1 year ago.
0

I haven't yet implemented other APIs, but couldn't you just include a get variable in the request, something like http://url.com/?json=1

And then the controller could return JSON, otherwise return a view.

Last updated 1 year ago.
0

MacWorks said:

I haven't yet implemented other APIs, but couldn't you just include a get variable in the request, something like http://url.com/?json=1

And then the controller could return JSON, otherwise return a view.

Well obviously I can hack it that way, but the idea here is that I do it as neatly as possible. That's the reason I'm building an API in the first place. I want to learn :)

Last updated 1 year ago.
0

bampidibamp

Last updated 1 year ago.
0

You could create a controller called ApiController and route to it with Route::resource("/api", "ApiController")

From there you should give this a read.

Edit gave wrong link

Last updated 1 year ago.
0

Resource controllers can help in building an API.

But its better to first design the API. At least in scratch pad. Realize what resources are going to be available , how authentication is going to be managed. How are you going to manage incremental updates to the API and to ensure that it doesn't break existing integration's , versions etc ...

Last updated 1 year ago.
0

Apart from MacWorks, I don't believe any of these are answering the original question which is how to expose similar functionality across both an api and a web front end. MacWorks' idea of using a query arg would work (as would most things given enough pain and effort) but it's not ideal and would normally be used as a form of api content negotiation (in which case just use http content negotiation) and not for use in a case like this.

Unsurprisingly this situation is very common. Lots of sites expose their data over an api and also have their own front end over the top. They certainly aren't writing the whole thing twice! The root of the problem here is that you're thinking in terms of controllers and adding all of the necessary logic to them, the end result of which is a bad case of what is known as The Fat Controller (Thomas the Tank Engine has been a big MVC fan for years). Fat controllers aren't bad in themselves but when you're trying to implement multiple presentations over the same data/logic it's a dangerous trap to fall into. Assuming a simple case of authenticating a user, querying some data in a db, maybe generating an email, some diagnostic logging, etc... putting this all in the controller is fine for a quick and dirty site or when you're doing a short proof of concept but you'll eventually hate yourself for it.

A much better approach commonly used is the notion of command objects which encapsulate all of the necessary request context data and trigger the processing of your exposed actions, returning the result back to the controller (see here for a great course/intro - https://laracasts.com/series/commands-and-domain-events. When you've finished watch every other video Jeremy has produced, they're all solid gold!). In your case the command result is then simply returned to the API controller for serialization on the wire.

The web controller can generate and post the exact same command and return whatever is appropriate in this case, e.g. passing the command response to a view and returning the rendered html.

The end result is you have a thin routing/controller layer just posting command objects into a bus and returning the result on the wire in whatever format you need. If you need to modify some logic or add additional steps to your process, you have a nice clean architecture in which to make these changes and instantly see the results in both API & Web simultaneously.

Finally, yes of course you could have a fat API controller design, make one big giant class handling all of your logic, delegate your web controller calls to this, decode the json, pass it to the view, and so on.. however that's layering one bad design on top of another and another and given one of your objectives is to learn, I suggest learning good practices from the start. Like all things, development bad habits are just as hard to break as any other.

HTH

Last updated 1 year ago.
0

Sign in to participate in this thread!

Eventy

Your banner here too?

Ortix92 ortix92 Joined 8 Feb 2014

Moderators

We'd like to thank these amazing companies for supporting us

Your logo here?

Laravel.io

The Laravel portal for problem solving, knowledge sharing and community building.

© 2024 Laravel.io - All rights reserved.