2015-02-26 17 views
5

Mam problemy filozoficzne w mojej strukturze DRF za pomocą handlarza płatności Stripe. Sprzedaję produkt, który ma model django Product poprzez mój interfejs API REST DRF. Zastanawiam się, czy należy utworzyć Product a następnie obsługiwać płatności w moim create widzenia następująco:Django Rest Framework and Stripe, najlepsza praktyka?

class ProductViewSet(viewsets.ModelViewSet): 

... 

def create(self, request): 
    serializer = ProductSerializer(data=request.data) 
    serializer.is_valid(raise_exception=True) 
    product = serializer.save() 

    try: 
     response = stripe.Charge.create(
      amount=product.cost, 
      currency="usd", 
      source=request.data["token"], # Done with Stripe.js 
      description="Product" 
     ) 
     product.charge_id = response.charge_id 

     ... 

lub zamiast tego, czy należy obsłużyć PAYEMENT w serializatora z Product:

class ProductSerializer(serializers.Serializer): 

    ... 

    def create(self, validated_data): 
     product = Product.objects.create(**validated_data) 

     # Will raise an Excetpion and stop the creation: 
     response = stripe.Charge.create(
      amount=product.cost, 
      currency="usd", 
      source=validated_data["token"], # Done with Stripe.js 
      description="Product" 
     ) 


     return product 

Która z nich jest lepszą praktyką? Czy też całkowicie pomijam ten punkt i powinienem zrobić to inaczej?

Po drugie, czy istnieje sposób na osadzenie Stripe.js i wymaganego formularza w szablonie interfejsu API do przeglądania dla trasy create, aby przetestować mój REST bez potrzeby jakiegokolwiek frontendu?

Dziękuję za pomoc

Odpowiedz

1

moim zdaniem właściwe podejście jest mieszanką dwóch przewidzianych podejść poniewaz należy wysłać Stripe wniosek w klasie ModelViewSet ale zapisać podmiot Product dopiero po pomyślnej odpowiedzi usługi.

W przeciwnym razie, jeśli odpowiedź serwisu nie powiedzie się, wycofałbym każdą operację bazy danych (z Django 1.6+ można to zrobić, korzystając z transaction.atomic() udokumentowanej here).

Nie podoba mi się twoje drugie podejście, ponieważ zgodnie z dokumentacją DRF o metodzie create z serializers.Serializer ta metoda powinna zwracać tylko nową instancję Entity ze względu na sprawdzone dane, więc nie dodaję innej logiki biznesowej.

Jeśli chodzi o drugie pytanie chciałbym uporządkowania sposobu create do korzystania z wtryskiwanego atrapa obiektu na żądanie Stripe, w ten sposób można przetestować swój kod dotyczącą jakiejkolwiek interakcji frontend (oczywiście w ten sposób nie zrobić test integracji ale test jednostkowy).

+0

Dzięki. Po prostu ładuję po sprawdzeniu danych 'serializer.is_valid (raise_exception = True)', ale przed utworzeniem obiektu 'product = serializer.save()' w moim widoku. To trochę smutne, że muszę pobierać niektóre dane z 'request.data', by ładować ... Czy możesz dodać więcej szczegółów (np. Bit kodu) w drugiej części? – user2024621