I'm confused between the concepts of Odoo RPC, XML RPC, JSON RPC, and REST API in the domain of Odoo. To my knowledge, these are the only 4 APIs that can be used in Odoo.
In Odoo's documentation, only xml rpc and json rpc are mentioned. But on this website: Odoo RPC They've discussed Odoorpc library. Fourth one is REST API, how does it fit in odoo? When we create a controller with a specific route, would it be called a REST API?
RPC and REST are different approaches to how to call an API. RPC is a bit harder to use but more powerful, REST is easier but less powerful.
Odoo only has one API: RPC. Odoo has no REST API.
You can call Odoo's RPC it through XML-RPC or JSON-RPC, but the API is the same. Just use the format that best fits your other system. In case you don't care, go for JSON-RPC, which is the one odoo itself uses.
The docs you link are unofficial, and the odoorpc lib is another unofficial library that makes interacting with odoo API more comfortable. These are the official docs: https://www.odoo.com/documentation/14.0/webservices/odoo.html
Related
I read some articles and i search many about differences between Rest WCF vs Web api but I just find difference between WCF vs Web api , I find some difference:
WCF Rest=>
a)It support HTTP GET and POST verbs by [WebGet] and [WebInvoke] attributes respectively.
b)To enable other HTTP verbs you have to do some configuration in IIS to accept request of that particular verb on .svc files.
c)Passing data through parameters using a WebGet needs configuration. The UriTemplate must be specified.
d)It support XML, JSON and ATOM data format.
and
WebApi=> a)Unlike WCF Rest service, it use the full featues of HTTP (like URIs, request/response headers, caching, versioning, various content formats).
b)Responses are formatted by Web API’s MediaTypeFormatter into JSON, XML or whatever format you want to add as a MediaTypeFormatter.
I want know other differences between them, and when is it better to use WebApi and when Rest Wcf?
I would say, if you start a new project and you need to expose a REST web interface in .NET, Web API is the way to go because AFAIK, WCF is deprecated. I would only consider to use WCF Rest if you have to expose both, SOAP and REST web interfaces.
WCF is not the good choice for REST because it was not made for it, when they implemented it they did lots of bad hacks. you can see how they try to convert xml to josn here
WCF is NOT deprecated, so powerful, and no framework can be comparable to it yet. but it is not for REST.
Why Google uses a lot of SOAP in spite of the following advantages in REST.
REST is an architectural style.
REST stands for REpresentational State Transfer.
REST can use SOAP web services because it is a concept and can use any protocol like HTTP, SOAP.
REST uses URI to expose business logic. REST uses (generally) URI and methods like (GET, PUT, POST, DELETE) to expose resources. JAX-RS is the java API for RESTful web services.
REST does not define too much standards like SOAP.
REST requires less bandwidth and resource than SOAP.
RESTful web services inherits security measures from the underlying transport.
REST permits different data format such as Plain text, HTML, XML, JSON etc.
REST more preferred than SOAP.
REST is an architectural style, unlike SOAP which is a standardized protocol.
REST follows stateless model
REST has better performance and scalability. REST reads can be cached. JSON usually is a better fit for data and parses much faster
No accepted standard for a JSON schema.
SOAP
SOAP is a protocol.
SOAP stands for Simple Object Access Protocol.
SOAP can't use REST because it is a protocol.
SOAP uses services interfaces to expose the business logic. JAX-WS is the java API for SOAP web services.
SOAP defines standards to be strictly followed.
SOAP requires more bandwidth and resource than REST.
SOAP defines its own security.
SOAP permits XML data format only.
SOAP is less preferred than REST.
SOAP is actually agnostic of the underlying transport protocol and can be sent over almost any protocol such as HTTP, SMTP, TCP, or JMS.
SOAP has a standard specification
SOAP has specifications for stateful implementation as well.
SOAP based reads cannot be cached.
The marshalling costs are higher but one of the core advantages of XML is interoperatibility. For XML, a schema allow message formats to be well-defined. Data typing and control is also much richer under XML.
Thanks in advance.
Steve Francia has a great comparison article on the subject, though I was under the impression (and Steve mentions) that Google had moved away from SOAP to REST. I would be curious if you are asking about a specific API? Then maybe I could formulate a more specific answer regarding that API.
However, overall, while REST is superior in almost every way, here is why you would use SOAP:
Web Service Security - SOAP supports WS-Security in addition to SSL, which adds some enterprise security features and identity through intermediaries, not just point to point (SSL). It also provides a standard implementation of data integrity and data privacy.
Web Service Atomic Transaction - WS-AtomicTransactions are necessary if you need Transactions that are ACID compliant (though probably not why Google would have been using it).
Web Service Reliable Messaging - SOAP has standard messaging through WS-ReliableMessaging, enabling built in successful/retry logic and provides end-to-end reliability even through SOAP intermediaries.
I'm looking for best way to automate generation of REST ws.
We have collection of web services (SOAP) with WSDLs generated for them. I was required to provide different APIs to invoke these web services. (PHP, Pyton, REST, CLI ...)
One of requirement is to have REST API for these ws.
What is the best way to generate REST client/server, is there any automatic tools for that?
There is a chance that WSDLs will change each release.
Thanks
It's not possible to generate REST API from WSDL. You can't mix oranges and apples
SOAP is a protocol build on top of HTTP. A WebService is represented by a set of methods/actions. You can see a WebService as sophisticated RPC. Generally we can say that WebServices are about verbs, to call remote methods/actions. A WebService also doesn't have uniform interface and that's the reason why WSDL exists.
REST is architectural style (scope is broader than just API). REST API is represented by a set of resources and representations. A resource is source of an information and is managed via uniform interface. Generally we can say that REST API is about nouns. Because all resources must have uniform interface there is no need for WADL (an unsuccessful attempt to create something like WSDL for REST).
I doubt you can automatically transform verbs into nouns, etc.
Please check the below article that describes how to use WSDL2.0 to describe REST Services. It can only be used if the intended message format is XML.
https://www.ibm.com/developerworks/library/ws-restwsdl/
Instead of rewriting an existing SOAP-based web service, use API Express to present it as a mobile-ready REST service. No conversion necessary. Continue to run the SOAP service and, with a WSDL file and a few configuration parameters, it can easily be integrated into mobile apps as a REST service.
How to Expose a WSDL Service (SOAP) as REST API: https://dzone.com/articles/how-to-expose-a-wsdl-service-soap-as-rest-api
Appery.io API Express: https://appery.io/api-express/
I am working with a CRM System that provides two types of APIs: servlet API & REST API, both of which are over HTTP.
I used to integrate with REST API from my ASP.NET MVC web application by calling the REST URL and manipulating the returned JSON or XML. But I cannot figure out what is meant by a servlet API and can these APIs be called over the web from my ASP.NET MVC application or these APIs should be called inside a Java application?
Sorry if my question seems trivial to someone.
The Java Servlet API refers to a set of classes used to implement server side programs. The main player is the Servlet:
A servlet is a small Java program that runs within a Web server. Servlets receive and respond to requests from Web clients, usually across HTTP, the HyperText Transfer Protocol.
If you want a very simplistic analogy, the Servlet is Java's version of CGI (Common Gateway Interface).
A REST API is a way to build applications by fully using the architecture of the web. Leaving all details of REST aside and grossly simplifying, it's basically a HTTP API.
If you want to build a HTTP API, you can use Servlets. So you can also use servlets to build a REST API although there are better alternatives to that (e.g. JAX-RS) because servlets are a "low level" component and nothing shields you from all the boiler plate code you need to write.
You can of course call a Java application build on top of the Servlet API from other clients (e.g. from ASP.NET MVC). That's what it was built for. For this reason I don't really understand what exactly your CRM system means by a Servlet API and (a separate!?) REST API... so maybe ask the CRM provider?
EDIT : Based on what I've read about the ManageEngine Service deskPlus APIs, I'm thinking that this is just an unfortunate name chosen by the provider.
As I mentioned in my comments, when you say REST API you already provide some information from the beginning. Most people, when told about REST understand that you have some abstract resources, that these resources can have multiple representations (JSON, XML, whatever), that each resource is identified by a URI, that /customers is referring to a list of customers resources, that /customers/1 is a customer and that /customers/2 is another one, that you use GET /customers/1 to find out details about the customer and DELETE /customers/1 to delete it etc.
REST is one way to interact with an application, another one is to expose operations that can be called by clients, for example like what SOAP is doing. Before REST became the new kid in town people were doing stuff with SOAP. Unlike accessing resources, SOAP is focused on accessing operations. When you mention SOAP to someone she knows that it's a protocol that can use HTTP's POST to transmit messages around, that each message has an XML payload that contains the operation name to invoke and the parameters needed for the call etc.
But even before SOAP and REST becoming widely known, people realized that they can use a form submit to sneak in RPC calls through HTTP. The HTTP form based submission is one of the methods of the API in ManageEngine Service deskPlus. But the form based submission method (as far as I know) doesn't have a cool name like SOAP or REST... so maybe that's why it was named after the Servlet API?! (I'm once again emphasizing that this is just the server implementation which is not important in the context of the HTTP protocol).
So to conclude: Yes, you CAN call the ManageEngine Service deskPlus Servlet API from ASP.NET, even a web browser or any kind of HTTP capable client.
I have been reading about REST and SOAP, and understand why implementing REST can be beneficial over using a SOAP protocol. However, I still don't understand why there isn't the "WSDL" equivalent in the REST world. I have seen posts saying there is "no need" for the WSDL or that it would be redundant In the REST world, but I don't understand why. Isn't it always useful to programmatically bind to a definition and create proxy classes instead of manually coding? I don't mean to get into a philosophical debate, just looking for the reason there is no WSDL in REST, or why it is not needed. Thanks.
The Web Application Description Language (WADL) is basically the equivalent to WSDL for RESTful services but there's been an ongoing controversy whether something like this is needed at all.
Joe Gregorio has written a nice article about that topic which is worth a read.
WSDL describes service endpoints. REST clients should not be coupled to server endpoints (i.e. should not be aware of in URLs in advance). REST clients are coupled on the media-types that are transfered between the client and server.
It may make sense to auto generate classes on the client to wrap around the returned media-types. However, as soon as you start to create proxy classes around the service interactions you start to obscure the HTTP interactions and risk degenerating back towards a RPC model.
RSDL aims to turn rest like a hypermedia, in other words, it has more information than a service descriptor like WSDL or WADL. For example, it has the information about navigation, like hypertext and hyperlinks.
For example, given a current resource, you have a set os links to another resources related.
However, i didn't find Rest Clients that supports this format or Rest Server Solutions with a feature to auto generate it.
I think there is a long way for a conclusion about it. See the HTML long story and W3C vs Browsers lol.
For more details about Rest like Hypermedia look it: http://en.wikipedia.org/wiki/HATEOAS
Note : Roy Fielding has been criticizing these tendencies in Rest Apis without the hypermidia approach: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
My Conclusion : Now a Days, WADL is more common that Rest and Integration Frameworks like Camel CXF already supports WADL ( generate and consume ), because it is similar to WSDL, therefore most easy to understand in this migration process ( SOAP to REST ).
Let's see the next chapters ;)
Isn't it always useful to programmatically bind to a definition and
create proxy classes instead of manually coding?
Agree wholeheartedly, this is why I use Swagger.io
Swagger is a powerful open source framework backed by a large
ecosystem of tools that helps you design, build, document, and consume
your RESTful APIs.
So basically I use Swagger to describe my models, endpoints, etc, and then I use other tools like swagger-codegen to generate the proxy classes instead of manually coding it.
See also: RAML
There is an RSDL (restful service description language) which is equivalent to WSDL. The URL below describes its practice http://en.wikipedia.org/wiki/HATEOAS and http://en.wikipedia.org/wiki/RSDL.
The problem is that we have lots of tool to generate code from wsdl to java, or reverse.
But I didn't find any tool to generate code from RSDL.
WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate
However, REST uses the network protocol by using HTTP verbs and the URI to represent an objects state.
WSDLs tell you at this place, if you send this message, you'll perform this action and get this format back as a result.
In REST, if I wanted to create a new profile I would use the verb POST with a JSON body or http server variables describing my profile to the URL /profile
POST should return a server-side generated ID, using the status code 201 CREATED and the header Location: *new_profile_id* (for example 12345)
I can then perform updates changing the state of /profile/12345 using the HTTP verb POST, say to change my email addresss or phone number. Obviously changing the state of the remote object.
GET would return the current status of the /profile/12345
PUT is usually used for client-side generated ID
DELETE, obvious
HEAD, gets the status without returning the body.
With REST it should be self-documenting through a well designed API and thus easier to use.
This is a great article on REST. It really help me understand it too.
WSDL 2.0 specification has added support for REST web services too. Best of both worlds scenario. Problem is WSDL 2.0 is not widely supported by most tools out there yet. WSDL 2.0 is W3C recommended, WSDL1.1 is not W3C recommended but widely supported by tools and developers.
Ref:
http://www.ibm.com/developerworks/library/ws-restwsdl/
The Web Application Description Language (WADL) is an XML vocabulary used to describe RESTful web services.
As with WSDL, a generic client can load a WADL file and be immediately equipped to access the full functionality of the corresponding web service.
Since RESTful services have simpler interfaces, WADL is not nearly as necessary to these services as WSDL is to RPC-style SOAP services.