Pytanie Napisz opakowanie, aby udostępnić istniejące interfejsy API usług REST jako usługi sieciowe SOAP?


Mam istniejące API REST, napisane przy użyciu Django Rest Framework, a teraz ze względu na pewne wymagania klienta muszę ujawnić niektóre z nich jako usługi sieciowe SOAP.

Chcę wiedzieć, jak napisać wrapper w Pythonie, dzięki czemu mogę odsłonić niektóre z moich API REST jako usługi sieci web SOAP. Czy powinienem osobno tworzyć usługi sieciowe SOAP i ponownie używać kodu?

Wiem, że to dziwna sytuacja, ale każda pomoc byłaby bardzo doceniana.


14
2017-07-24 11:13


pochodzenie


I ? Jakie jest dokładnie twoje pytanie? - bruno desthuilliers
Chcę wiedzieć, jak napisać wrapper w Pythonie, dzięki czemu mogę odsłonić niektóre z moich API REST jako usługi sieci web SOAP. Czy powinienem osobno tworzyć usługi sieciowe SOAP i ponownie używać kodu? - Ankur Sharma
Cóż, czego próbowałeś? - bruno desthuilliers
Obecnie oceniam obie opcje. Jestem bardziej skłonny do pisania oddzielnych usług sieciowych SOAP, a następnie ponownego użycia kodu wewnętrznego. Problem polega jednak na tym, że w przyszłości może będę musiał ujawnić więcej tych interfejsów API w postaci usługi sieciowej SOAP, więc myślę, że może jakiś rodzaj opakowania może zostać wykorzystany do udostępnienia tych interfejsów zarówno jako usługa sieciowa SOAP, jak i interfejsy API REST. - Ankur Sharma


Odpowiedzi:


Możesz powiedzieć, SOAP i REST są w zasadzie apples i oranges.

Zasadniczo potrzebujesz czegoś, gdzie możesz spożywać REST API.

Jak widzę, masz kilka opcji:

  • Użyj usługi SOAP oddzielnie na innym porcie (punkcie końcowym). W tym celu chciałbym powiedzieć, że korzystam z frameworków Spyne sprawdź próbkę Witaj świecie
  • Użyj preferowanego sposobu klienta, albo SOAP przez WSGI, albo SOAP via HttpRPC
  • Wywołaj te same punkty końcowe interfejsu API REST, które zostały utworzone za pomocą metod w SOAP. Użyliśmy wewnętrznego opakowania APi w jednej z aplikacji, która jest następująca:
def wrap_internal_api_call(requests_api_method, uri, 
                           data, cookies=None, headers=None):

    return requests_api_method(uri, data=data, files=files, 
               cookies=cookies, headers=headers)

Jak możesz tego użyć?

import requests

from django.core.urlresolvers import reverse
from django.conf import settings

from spyne.service import Service
from spyne.decorator import srpc
from spyne.model import ByteArray, DateTime, Uuid, String, Integer, Integer8, \
    ComplexModel, Array


# This method will hit the internal API which is written in DJANGO REST FRAMEWORK
def build_internal_uri(uri):
  return 'http://localhost:{0}{1}'.format(settings.INTERNAL_API_PORT, uri)


class RequestHeader(ComplexModel):
  some_field = String


class SomeService(Service):
    # Headers related doc
    # https://github.com/arskom/spyne/blob/68b9d5feb71b169f07180aaecfbe843d8ba500bf/doc/source/manual/06_metadata.rst#protocol-headers 
    __in_header__ = RequestHeader

  @srpc(String, _returns=String)
  def echo_string(s):
    headers = ctx.in_header.some_field

    # Reverse url from the urls.py file
    local_order_fetch_url = build_internal_uri(reverse('website:order_details')) + '?order_id=' + order_id

    response = wrap_internal_api_call(requests.get, local_order_fetch_url, 
            { 'data': 'sample_data' }, None, headers)

    return response['data'] # Some string data


app = Application([SomeService], 'tns', in_protocol=HttpRpc(parse_cookie=True), 
                out_protocol=HttpRpc())

Teraz jest kilka przykładów, na które można się przyjrzeć, będąc konfiguracją Django do jej tworzenia dostępny


9
2017-07-27 10:02





Omówmy zarówno podejścia, jak i ich za i przeciw

Oddzielna usługa SOAP 

  • Ponowne użycie tego samego kodu - jeśli jesteś pewien, że zmiany w kodzie nie wpłyną na przepływ dwóch kodów, dobrze jest jechać.
  • Rozszerzenie funkcji - Jeśli masz pewność, że nowe rozszerzenie funkcji nie wpłynie na inne części, najlepiej ponownie.
  • Skalowalność - jeśli nowe API są częścią tej samej aplikacji i masz pewność, że będzie skalowalny przy większym obciążeniu, jest to znowu dobra opcja.
  • Rozbudowa - Jeśli jesteś pewien, że w przyszłości dodanie więcej API nie spowoduje bałaganu w kodzie, to znowu dobrze jest iść.

Opakowanie mydła za pomocą Pythona (moja ulubiona i sugerowana droga)

  • Rozdzielenie koncernu dzięki temu możesz upewnić się, że kiedykolwiek napisałeś kod, jest sperate od głównej logiki i możesz łatwo podłączyć i podłączyć nowe rzeczy.

Odpowiedz na wszystkie powyższe pytania, jeśli tak, to TAK.

Twoja decyzja ,

Komentarze i komentarze są mile widziane


0
2017-08-02 10:47



Przed głosowaniem w dół proszę podać przyczynę - Vijay Parmar
przeczytaj ponownie pytanie - maszynka
@maszynka dzięki za wskazanie. - Vijay Parmar