I am working on a large api, it tries to be restful (and for most part it succeeds), one of our client requires a term of service in html format.
Is it ok to have a endpoint that returns html in a restful json api? Are there better alternatives?
I believe it's best to have the client dictate the content type via Accept header in the HTTP request. You can default to application/json and have the client call the API they require with a text/html Accept header.
It is okay for RESTful services to return any media type, as long as the API itself is agnostic of it.
Related
I'm working with an old ERP system that is capable of sending SOAP requests.
Unfortunately the endpoints I would like to send my requests to uses REST.
Is it possible to send a SOAP request to a REST endpoint?
BR Kresten
You can send whatever you want to a REST endpoint.
You could have a "gatekeeper" REST endpoint that accepted SOAP in a POST payload and converted it to whatever representation the other endpoints required and returned that representation. e.g. JSON. So in effect it becomes a SOAP to JSON converter.
If you can only send SOAP direct from an ERP system to your endpoint, your endpoint could accept the SOAP in a POST request and do whatever it wanted with it. SOAP is just XML, so the endpoint could just parse it to get the info it would "normally" get via "traditional" REST such as JSON.
You could combine the two approaches. Your ERP system could send SOAP to the "gatekeeper" endpoint which converts the SOAP to JSON and sends the converted content to the intended endpoint.
We have multiple API's running for an enterprise. As per our limitation client will allow only one static IP to receive all Inbound/Outbound requests.
So, we need to expose a single API as a bridge between the client system and API's running behind.
How to approach this design?
How to design the URL for this proxy API?
What edge functions does this API need to provide?
Any help would be highly appreciated. Thanks!
You do not need to use web services consumer, yet will need to create a POC.
Define A RAML with required path and RAML, scaffolding should give you API took kit, and connect an HTTP request
use HTTP request
Examples:
Define Headers --- attributes.headers.id etc
queryParams ---- attributes.queryParams.date
if you are sending JSON payload across from ex: postman, change Mime type to application/json
sample http properties for request
http.host=myHost
http.port=8872
http.base.path=/myproxy/services
Do both SOAP and REST refer back to the WSDL? I'm having trouble distinguishing between SOAP and REST.
No, only SOAP does.
Essentially SOAP is a protocol with the client and server making agreements as to the kinds of data types transmitted and what actions should be taken by the server for a request. This agreement is specified in the WSDL file.
With REST, there is no agreement as the point of REST is to talk to a resource using only GET, POST, PUT, and DELETE. Nothing about the underlying implementation as specified by a WSDL file should be known to a REST client.
I am having confusion around http text 'post' in terms of webservice context. We are having a web service which is built on SOAP protocol, now the integration partner wants to eliminate the SOAP portion of the XML message and wants us to post XML message as 'http text post'.
Is this REST HTTP POST? Please clarify.
POST is an HTTP request method, of which there are many (ex. GET, PUT, DELETE, HEAD...). POST is used to submit data to a server for processing, whereas GET (for example) is used to retrieve data for reading. You can read more here. These methods are used for all HTTP communication, whether the target is a SOAP/REST web service or an Apache server hosting a regular website.
SOAP normally operates using POST requests, although it is possible to use GET with SOAP 1.2 as well. GET requests have more restrictive size limitations than POST requests.
Is it a good idea to show documentation of a particular REST resource if clients Content-Type is other than application/json? I mean, if a developer tries to fetch a REST resource URL in browser he gets something like this.
Although this is open for discussion but in my opinion that would be a bad idea. The whole purpose of a RESTful API is to expose your application interface for other developers to use. Some developer look at http header to determine if certain route of your REST API existed regardless of the content-type. If I request for a text/plain, I would expected to receive a 404/NotFound if you don't have it and not a documentation with a 200/OK. Although, I suppose it could be useful for manual API testing with browser.