In the laravel docs they have explained using resourceful controllers for using REST and using verbs in the methods of the controllers.
I have manually listed all my routes like this:
Route::get('users/{id}/friends', 'UsersController#friends');
I am not using any resource just the method and the uri.
How can I make this restful? Or is it restful already? Then how do I call the methods in a RESTful manner? I am confused
REST is nothing more than a convention on how data should transfer in the web. If you want to be all nitpicky about it check this out: http://en.wikipedia.org/wiki/Representational_state_transfer#Architectural_constraints
As for laravel, when you generate a controller via the CLI like so:
php artisan controller:make UsersController
Laravel automatically creates the boiler plate for the various actions you need to be handling (create, store, destroy, update and so on.) and then you can set-up your routes. Of course you wont need all for most controllers.
Here's a helpful set of links from Phillip Brown's blog:
http://culttt.com/2013/07/01/setting-up-your-first-laravel-4-controller/
http://culttt.com/2013/08/12/building-out-restful-controller-methods-in-laravel-4/
If you want to make it RESTful, the simplest way in laravel is to do Route::resource('user', 'UserController), which automatically gives you the routes shown on the laravel web page.
However, if you are trying to look up the friends RESTfully you would want to make a /friends/ resource, and then register it as Route::resource('friends', 'FriendController'). For more on the relationships/friends side of things I would suggest reading this question from 2011, while not laravel specific, it does answer questions about REST.
Related
I have several services, each one exposed through REST API with ASP.NET Core Web API. I use Swashbuckle for ASP.NET Core tooling in order to automatically generate from my controllers and DTOs all the necessary documentation and visualize it in SwaggerUI. I found this tooling really great, with little annotations on my models and my controllers already provides many features out of the box, such as a UI client to try out the REST API endpoints.
But with this solution each service has its own dedicated SwaggerUI instance and therefore UI.
I would like to offer to my customers a wiki-like documentation with a navigation menu, where, for instance, they can browse sections regarding all the endpoints exposed by my services and have on each page the same features offered by SwaggerUI.
It can be achieved by creating my own web application but I was wondering whether an out of the box solution or some tool that might ease such integration already exists.
I tried Slate but I felt like I had to re-invent the wheel in order to automate at least the creation of the basic API documentation, namely controller definition, response definition and descriptions. Does anyone have any suggestion?
I faced this very issue recently working in a microservices architecture, you're absolutely right. There is not need to reinvent the wheel.
I really can't recommend redoc by Redocly enough in this case.
Have a look at the multiple-apis example.
As far as I understood, unlike Rails, Yii2 still doesn't use RESTful routing for CRUDs.
What could be the most efficient way to generate new CRUD with gii and add REST routing support to it?
I've done some background search and found the following:
a lot of information about how to easily build REST API application - http://www.yiiframework.com/doc-2.0/guide-rest-quick-start.html (which is not a thing I really need - it's only useful for backend applications)
an article by qiangxue https://github.com/yiisoft/yii2/blob/master/docs/guide/rest-routing.md on how to enable REST routing for CRUDs
a gist added by cebe (https://gist.github.com/cebe/5674918) doing almost the same thing like qiangxue proposed in other way
So it's all about configuring UrlManager and implemetation of backend API applications.
Unfortunately, I also need to somehow add a REST routing support to CRUD controller generated by default (with its verb-based filters and a base class that is not specialized for REST, unlike yii\rest\ActiveController for example). At the same time a generated by default GridView widget code doesn't support REST routes, but only utilizes GET+POST verbs.
Really appreciate certain list of things to do :)
Does anyone have any sample code on how to create a RESTful application that gets information from a database? I would like to implement the conditional-GET like Vinoski talks about, I'm just not sure how to go about it. I have created a SOAP application using CRUD and I'll like to try and compare it to GET, PUT, POST and DELETE
Thanks
From all the various examples of Ember.js, I have not been able to figure out if there is a default method in Ember.js to do REST AJAX calls. Many examples build their own interfaces for CRUD operations. I even tried to sift through the code to find any reference to AJAX calls but came up with nothing.
So, my question is, is there a default implementation of REST API in Ember.js. If yes, how do I use it? Also if, for a specific application, I want to build custom CRUD methods, where do I plug these into Ember.js?
It seems that Ember Data is what you are looking for. It is part of emberjs organiztion in GitHub.
[2014-02-18: Deprecated - I no longer support ember-rest because it is overly simplistic, and would recommend using ember-data for most ember projects. Check out the Ember guides for an overview of ember-data as well as this example project ]
While learning Ember, I decided to create a very simple Ember REST library. I also wrote an example Rails CRUD app.
My goals were to keep this project as simple as possible, while still including error handling and validation. Ember REST is certainly much leaner than Ember Data and Ember Resource, and I hope you'll find the code well commented and accessible.
There is a Ember Resource library aiming REST JSON interfaces. It provides Ember.Resource class with save(), fetch() and destroy() operations that could be easily overriden. Looks like it should be more mature than Ember Data for now.
Ember.js can work nicely with Ember Data. That said, there is a specific format of REST to follow. When followed, you can streamline the process of connecting API with Ember and have so much less work.
In case you use custom REST, the place to adjust is:
adapter - to inform from where you like to get data
serializer - how data should be adjusted for custom REST API
I see a lot of articles and posts on how to create a custom MembershipProvider, but haven't found any explanation as to why I must/should use it in my MVC2 web app. Apart from "Hey, security is hard!", what are critical parts of the whole MembershipProvider subsystem that I should know about that I don't, because I've only read about how to override parts of it? Is there some "behind the scenes magic" that I don't see and will have to implement myself? Is there some attribute or other piece of functionality that will trip over itself without a properly setup MembershipProvider?
I am building a web app, using a DDD approach, so the way I see it, I have a User entity and a Group entity. I don't need to customize ValidateUser() under the provider; I can just have it as a method on my User entity. I have to have a User object anyways, to implement things not under the MemebrshipProvider?
So, what gives? :)
No, you don't need it. I have sites that use it and sites that don't. One reason to use it is that plumbing is already there for it in ASP.NET and you can easily implement authentication by simply providing the proper configuration items (and setting up the DB or AD or whatever).
A RoleProvider, on the other hand, comes in very handy when using the built-in AuthorizeAttributes and derivatives. Implementing a RoleProvider will save you a fair amount of custom programming on the authorization side.