Sunday, January 29, 2017

REST API Subscriptions and transactions(payments) endpoints in Laravel

Leave a Comment

I am developing a web app and I observe REST API standards. I am searching for REST API best practice for subscription and payments.

When a new user subscribe for "pro plan", user should pay money for plan and it is a transaction.

Should I set POST: users/{id}/subscriptions and SubscriptionsController@store when new user subscribes?

And because subscription is a transaction and 2 separated request (before/after bank), all of subscribe codes should be in SubscriptionController@store?

For upgrade, cancel or updating a plan should I set PUT: users/{id}/subscriptions/{id} and SubscriptionController@update or other endpoint?

3 Answers

Answers 1

Generally you would not pass the user id in the route, unless there was some sort of authentication in the controller. eg. Admin is updating the user. Instead use the Auth::user() object in the controller.

With regard to your question, there are many options and it is entirely up to you, but a possible way of doing it would be to use a resource route\controller for this.

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

Then the controller would look something like this:

<?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     } } 

And your routes would be like this:

GET user/subscription list all user subscriptions index()

POST user/subscription create a user subscription store(Request $request)

GET user/subscription/{subscription_id} show a user subscription show($id)

PUT/PATCH user/subscription/{subscription_id} update a user subscription update($id)

DELETE user/subscription/{subscription_id} cancel a user subscription destroy($id)

Answers 2

I am trying to understand what you asking for but it's a little bit blur for me so if i got right , you are trying to figure what is the best practice for API End point naming , it's really depend on the functions you will provide and how you will expose the documentation.

But from my point i don't see a reason to chain User ID and Subscriber ID in the URL , i recommend something like this and you can pass all the information you want in the Body

$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'); 

it's really up to you how you define your endpoints

Answers 3

If your try for Braintree or Stripe both payment gateway through easily maintan plans and subscription.

Main Benifits :-

  1. Less coding for subscription and plan
  2. UI ready in Braintree tree drop-ui its reponsive
  3. Easily attach add-ons charges
If You Enjoyed This, Take 5 Seconds To Share It

0 comments:

Post a Comment