Я предлагаю вам для маршрута
Route::post('users/{id}/action', 'API\UserController@action');
и для запроса тела:
{
"act":"follow" //or unfollow
}
таблица:
public function up()
{
Schema::create('action_logs', function (Blueprint $table) {
$table->increments('id');
$table->integer('user_id')->unsigned();
$table->integer('object_id')->unsigned();
$table->enum('object_type',['USER','PAGE','POST']);
$table->enum('act',['FOLLOW','UNFOLLOW','VISIT' ,'LIKE','DISLIKE']);
$table->timestamp('created_at');
$table->foreign('user_id')->references('id')->on('users')
->onDelete('restrict')
->onUpdate('restrict');
});
//Or to make it easier
Schema::create('follower_following', function (Blueprint $table) {
$table->integer('follower_id')->unsigned();
$table->integer('following_id')->unsigned();
$table->primary(array('follower_id', 'following_id'));
$table->foreign('follower_id')->references('id')->on('users')
->onDelete('restrict')
->onUpdate('restrict');
$table->foreign('following_id')->references('id')->on('users')
->onDelete('restrict')
->onUpdate('restrict');
});
в модели (user.php) [ 118]
public function followers()
{
return $this->belongsToMany('App\User', 'follower_following', 'following_id', 'follower_id')
->select('id', 'username', 'name','uid');
}
public function following()
{
return $this->belongsToMany('App\User', 'follower_following', 'follower_id', 'following_id')
->select('id', 'username', 'name','uid');
}
метод действия: (если у вас есть страница и другой объект ... Лучше использовать этот метод в качестве черты)
public function action($id, Request $request)
{
// $user
switch ($request->get('act')) {
case "follow":
$user->following()->attach($id);
//response {"status":true}
break;
case "unfollow":
$user->following()->detach($id);
//response {"status":true}
break;
default:
//response {"status":false, "error" : ['wrong act']}
}
}
Таблица членства содержит информацию, относящуюся к интерфейсу API MembershipProvider . В таблице users хранятся имена пользователей и идентификаторы пользователей, на которые ссылаются многие поставщики.
Система aspnetdb является очень модульной, и каждый компонент может быть настроен через различных поставщиков. Таблицы должны быть разделены, чтобы каждый интерфейс можно было переписать, перенаправить и т. Д.
Честно говоря, для меня это тоже не имеет особого смысла. Кажется, что таблица aspnet_Membership была настроена для размещения информации о пользователе / уровне приложения, но UserID - это PK. Очень странно. Возможно, в какой-то более поздней версии вы настраивали себя для ситуации, когда у вас есть несколько приложений на пользователя.
Дейв упоминает, что есть другие таблицы, такие как aspnet_Profile, которые содержат специфичную для пользователя информацию. Возможно, пользователи ASP.NET 2.0 просто пытались разделить различные группы полей на более легко усваиваемые фрагменты. 1238 Я знаю, это всего лишь догадка. Надеюсь, кто-то с некоторыми фактическими знаниями будет вмешиваться.
Я нашел это объяснение из этого страница :
SqlMembershipProvider хранит информацию об учетной записи пользователя в двух связанных таблицах:
aspnet_Users - имеет запись для каждой учетной записи пользователя, в которой хранятся основные сведения. Столбец UserId однозначно идентифицирует каждого пользователя в системе и сохраняется как уникальный идентификатор (GUID).
aspnet_Membership - содержит столбец UserId, который связывает каждую запись с определенной записью в aspnet_Users. В таблице aspnet_Membership хранятся основные данные, связанные с каждой учетной записью пользователя: электронная почта, пароль, секретный вопрос и ответ и т. Д.
Некоторые другие провайдеры в ASP.NET (кроме провайдера членства) также хранят пользовательскую информацию. например, Профиль.
Подробнее об этом:
Некоторые из поставляемых поставщиков ASP.NET хранят / используют информацию в контексте имени пользователя. Одним из них является MembershipProvider , который обеспечивает хранилище аутентификации и набор услуг.
Другой является ProfileProvider , который позволяет хранить специфичные для пользователя данные против каждого пользователя.
] Вы все еще можете использовать ProfileProvider независимо от того, выбрали ли вы MembershipProvider или нет .
Поскольку ProfileProvider должен хранить данные под именем пользователя (т. Е. Как показано в свойстве Context.User.Identity.Name
), он добавит запись пользователя в aspnet_Users.
Надеюсь, это прояснит причину разделения.
aspnet_users
содержит пользователей, которых вы создаете (ФОРМЫ аутентификации) ... ПРИМЕЧАНИЕ, когда ваша аутентификация установлена на WINDOWS, пользователи являются пользователями WINDOWS, например domain \ firstname.lastname
aspnet_membership
содержит информацию о предпочтениях членства, используемую в таких вещах, как WebPart
и пользовательских настройках