10👍
You can say, SOAP
and REST
are basically apples
and oranges
.
You basically need something, where you can consume the REST API’s.
As I see, you have some options:
- Use a SOAP service separately running on another port (endpoint). For that I would say, use framework’s like Spyne check out sample hello world
- Use the clients preferred way, either SOAP via WSGI or SOAP via HttpRPC
- Invoke the same REST API endpoints which you created via the methods in SOAP.
We had used an internal api wrapper in one of application, which is as:
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)
How you can use this?
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())
Now there are some of examples which you can look into, being the Django configuration for making it available
0👍
Lets Discuss both the Approaches and their pros and cons
Seperate SOAP Service
- Reusing Same Code – if you are sure the code changes will not impact the two code flow ,it is good to go.
- Extension of Features – if you are sure that new feature extension will not impact other parts it is again best to go.
- Scalablity – if new API are part of same application and you are sure that it will be scalable with more load ,it is again a good option.
- Extension – if you are sure in future adding more API will not create a mess of code, it is again good to go for.
Soap Wrapper Using Python (my favourate and suggested way to go)
- Seperation of Concern with this you can make sure ,what ever code you write is sperate from main logic and you can easly plug in and plug out new things.
Answer for all the above question in case of this is YES.
Your Call ,
Comments and critisicsm are most welcome
Source:stackexchange.com