Alfred,
Good question. first some background.
You said
I intend to construct proxy for both REST call and xml pass-through call (i.e. POST + xml payload requests, and return xml responses, but not through SOAP)
It is sometimes assumed that "REST means JSON." This is not the case! I looked briefly for an article that discusses the idea in a few sentences but could not find one. So let me summarize the idea briefly here. REST = Representational State Transfer. It's a term referring to an architectural pattern that Roy Fielding described
in chapter 5 of his PhD dissertation. From that chapter:
The key abstraction of information in REST is a
resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author's hypertext reference must fit within the definition of a resource. A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.
A resource in your domain might be an order, a customer, a product entity, a book, a vacation property available for rent, a grade on a test; in short, whatever object or entity your domain uses.
There is also a mention in Ch5 regarding data formats.
The data format of a representation is known as a media type [
48]. A representation can be included in a message and processed by the recipient according to the control data of the message and the nature of the media type. Some media types are intended for automated processing, some are intended to be rendered for viewing by a user, and a few are capable of both.
This text doesn't say so, but... it follows that you can use ANY content-type to represent requests or responses in a REST system: application/json, application/xml, application/png, application/octet-stream, text/plain, text/html, text/xml, and so on.
So if you want to use Apigee to proxy XML-based RESTful APIs, no problem! Apigee Edge acts a proxy, and will pass through the content of the request unchanged from client to backend server.
The next questions to ask:
- will you do whitelisting in the API Proxy on the resources? For example, the XML API you are proxying might accept calls for collections of resources like /orders /customers and /books . You could design your Apigee API proxy to pass through every request it receives. This would mean a request for /sailboats would pass through to the backend, where presumably it would be rejected with "404 Not Found". alternatively you can design your Apigee API Proxy to whitelist the valid containers (/orders /customers /books ) via conditional flows in the API Proxy.
- Will you perform XML Schema verification in the API Proxy? Same idea as above; presumably the backend will accept only valid XML, according to some schema. If you like, you can have the Apigee API Proxy validate the body of inbound XML requests (let's say a POST to /books) to verify that the XML conforms to a schema.
- Will you verify credentials, tokens, or an API key in the API Proxy ?
-
Will you augment the API with
- extended error messages
- "default" values for some fields
- batching
- caching
All of these can be done in the Apigee API Proxy, without changing the backend.
The basic "pass through" proxy in Apigee will work just fine. If you want any of the above features or capabilities in your API, you can add them. in the API Proxy, using to the same approach that works with JSON or any other content-type.
I think by saying that you would like to implement a REST facade, you imply that you'd like the resource to be represented in application/json. That's no problem - you can do that via content negotiation - looking at the Accept header received from the client, and then transforming payloads with the JSONToXML policy and the XMLToJSON policy accordingly.
LinkedIn
Twitter
