Создать оболочку, чтобы открыть существующие API REST в качестве веб-служб SOAP?

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

Я хочу знать, как начать писать оболочку на python, чтобы я мог выставить некоторые из моих REST API как веб-сервисы SOAP. ИЛИ должен ли я делать веб-службы SOAP отдельно и повторно использовать код?

Я знаю, что это странная ситуация, но любая помощь будет очень благодарна.

Ответ 1

Можно сказать, SOAP и REST в основном apples и oranges.

В основном вам нужно что-то, где вы можете использовать API REST.

Как я вижу, у вас есть несколько вариантов:

Используйте службу SOAP отдельно, работая на другом порту (конечная точка). Для этого я бы сказал, используйте фреймворк, например Spyne проверить образец hello мир
Используйте предпочтительный путь клиентов, либо SOAP через WSGI, либо SOAP через HttpRPC
Вызывать те же конечные точки API REST, которые вы создали с помощью методов в SOAP. Мы использовали внутреннюю оболочку api в одном из приложений:

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)

Как вы можете это использовать?

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())

Теперь есть примеры, которые вы можете изучить, будучи конфигурацией Django для ее доступно

Ответ 2

Давайте обсудим как подходы, так и их плюсы и минусы

Отдельная служба SOAP

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

Мыло Wrapper с использованием Python (мой вариант и предлагаемый способ перехода)

Разговор о беспокойстве с этим вы можете убедиться, что код, который вы пишете, является отрывом от основной логики, и вы можете легко подключить и подключить новые вещи.

Отвечайте на все перечисленные выше вопросы, если это ДА.

Ваш звонок,

Комментарии и критика наиболее приветствуются