REST API Подписки и транзакции (платежи) конечные точки в Laravel

Question

Я разрабатываю веб-приложение, и я соблюдаю стандарты API REST. Я ищу оптимальную практику REST API для подписки и платежей.

Когда пользователь подписывается на «про план», пользователь должен заплатить деньги за план, и это транзакция.

Должен ли я устанавливать POST: users/{id}/subscriptions и SubscriptionsController@store, когда новый пользователь подписывается?

И поскольку подписка является транзакцией и 2 разделенными запросами (до/после банка), все коды подписки должны быть в SubscriptionController@store?

Для обновления, отмены или обновления плана я должен установить PUT: users/{id}/subscriptions/{id} и SubscriptionController@update или другую конечную точку?

Answer 1

Как правило, вы не должны передавать идентификатор пользователя на маршруте, если в контроллере не было какой-либо аутентификации. например. Администратор обновляет пользователя. Вместо этого используйте объект Auth::user() в контроллере.

Что касается вашего вопроса, есть много вариантов, и это зависит только от вас, но возможным способом сделать это было бы использовать для этого resource route\controller.

Route::resource('user/subscription', 'User\SubscriptionController');

Затем контроллер будет выглядеть примерно так:

<?php 

namespace App\Http\Controllers\User; 

use Illuminate\Http\Request; 
use Illuminate\Support\Facades\Auth; 

class SubscriptionController extends Controller 
{ 

    public function index() 
    { 
     // get user 
     $user = Auth::user(); 

     // list all user subscriptions 
    } 

    public function store(Request $request) 
    { 

     // get user 
     $user = Auth::user(); 

     if(empty($user)) { 
      // create user 
     } 

     // create and process subscription for the user 
     // possibly using a plan id in the $request 
    } 

    public function show($id) 
    { 
     // get user 
     $user = Auth::user(); 

     // return user subscription details for $id 
    } 

    public function update(Request $request, $id) 
    { 
     // get user 
     $user = Auth::user(); 

     // update or change user subscription 
     // possibly using a plan id in the $request 

    } 


    public function destroy($id) 
    { 
     // get user 
     $user = Auth::user(); 

     // cancel user subscription with $id 
    } 
} 

И ваши маршруты будут выглядеть так:

GETuser/subscription список всех подписок пользователя index()

POSTuser/subscription создать пользователя Подписка store(Request $request)

GETuser/subscription/{subscription_id} показывает подписки пользователя show($id)

PUT/PATCHuser/subscription/{subscription_id} обновления подписки пользователя update($id)

DELETEuser/subscription/{subscription_id} отменить подписку пользовательской destroy($id)

Answer 2

Я пытаюсь понять, о чем вы просите, но для меня это немного размывается, поэтому, если я прав, вы пытаетесь понять, что лучше всего подходит для именования конечной точки API, это действительно зависит от функций, которые вы предоставит и как вы будете раскрывать документацию.

Но с моей точки я не вижу причин для ID пользователя цепь и идентификатор абонента в URL, я рекомендую что-то вроде этого, и вы можете передать всю информацию, которую вы хотите в теле

$router->post('settings/user/plan', 'Settings\SubscriptionController@subscribe'); 
$router->put('settings/user/plan', 'Settings\SubscriptionController@changeSubscriptionPlan'); 
$router->delete('settings/user/plan', 'Settings\SubscriptionController@cancelSubscription'); 
$router->post('settings/user/plan/resume', 'Settings\SubscriptionController@resumeSubscription'); 
$router->put('settings/user/card', 'Settings\SubscriptionController@updateCard'); 
$router->put('settings/user/vat', 'Settings\SubscriptionController@updateExtraBillingInfo'); 
$router->get('settings/user/plan/invoice/{id}', 'Settings\SubscriptionController@downloadInvoice'); 

Это зависит от вас, как вы определяете конечные точки.

Answer 3

Если попробовать для Брэйнтри или полоски и оплаты шлюз грубые легкомысленные планы и подписки.

Основных ПРЕИМУЩЕСТВА: -

1. Меньше кодирование для подписки и планировать
2. UI готовы в Braintree дерево падения-интерфейсе его reponsive
3. Легко прикрепить Дополнение обвинения