I am trying to convert some of the SOAP based web services to Restful web services. In one of our existing SOAP based web service, we pass in a RequstDTO and the web service returns a ResponseDTO. The RequestDTO and ResponseDTO are both complex Java classes, which contain other custom JavaBean classes inside. It is a "READ" operation, so it naturally maps to the "GET" REST operation. Converting the ResponseDTO into XML or JSON has no issue. But I am not sure how to convert the RequestDTO into RESTful API.
The URL is going to be quite long, if I convert all the data in the RequestDTO into the query string. RESTful web service is usually consumed by application, thus the browser URL length limitation does not really apply. But a short URL is still preferred in most cases.
Some attributes in the RequestDTO might have PHI sensitive information and I prefer not to put them in the URL.
One solution is to embed the request data in the request body, even though it is a GET operation. But based on my research, such way is discouraged
http://tech.groups.yahoo.com/group/rest-discuss/message/9962
So what is the alternative? What is the right way to design this?
Im not exactly sure why you would need to pass the requestDTO to make the REST call.
Normally you just do something like this
GET /Resource/id
Now if the resource you want is like a secondary resource.. Example, you have a User and credit cards belonging to a user.
GET /User/{user_id}
GET /User/{user_id}/CreditCards/{credit_card_id}
And of course this can be nested however many times you want.
Related
I am a bit confused about the difference between the two.
What I have been making till now is just deploying a web application that gets invoked by a URL and returns a response(json/XML) .
what I have read about rest web services
Its a way to communicate with web applications and to reveal your methods to the world.
Question 1
But in my case I did the same revealing the URL .
Platform independent
The rest features say that its Language-independent (C# can talk to Java)
Question 2
But in traditional approach also any language can invoke any web service by simple request (get/post) which ever implemented.
Question 3
What is rest and how to get started with it (specifically in terms of django) if possible.?
You are doing REST.
REST is not a library, or a format, it's simply a technique. What you call the "traditional approach" is exactly what REST is: simple requests via GET and POST (as well as PUT and DELETE) to an endpoint that returns JSON or XML.
That is in contrast to the previously-dominant way of making API requests, ie SOAP, which requires all sorts of up-front configuration of WSDL files and service discovery, along with particularly specified request formats.
I don't exactly know what RESTFUL is. Sure I know it's a mapping of a URL to a resource. But how's that different from an ajax call to a codeigniter URL which echos some JSON?
My application will have subscriptions with states/options, is there any reason I should be using a RESTful setup rather than just some ajax calls when a user switches some of the options for their subscriptions?
You should not necessarily use "pure" REST. If your requirements drive you towards an HTTP-based service returning JSON, then great. But that doesn't imply that you need other aspects of the REST architectural style. You may not need:
An architecture based on resources, in the sense they're defined by the HTTP protocol
A URL structure that maps to resources
You may not want the return result from one request to provide a set of URLs which indicate "where to go" for related requests.
REST is an architectural style, but it can also become a "religion". Be certain that whatever you do is driven by the requirements you need to fulfill, and not based on "ideology".
I'm starting in the web-services world and I have a few questions:
From what I've read, REST could be understood as a simple call to a URL which gives a certain expected result. So, what is the difference between a REST web-service and a simple website?
Web-services are language-independent. So, if I'm developing a Java-based REST web-service with a method that returns a serialized Person class object, and my client is a .NET application, how can this class be reconstructed on the .NET side? How is it done in practice? Do I have to build a representation of the returned object on the web-service and on the .NET side parse it and build it?
In practice, whats is the difference between REST and SOAP calls?
See the Richardson Maturity Model for an explanation on what a RESTful service is.
To reach level 3 one must satisfy the Hypermedia as the Engine of Application State. abrivated HATEOAS constraint (also called the Hypermedia constraint). This means that most services out there is not RESTful, but merly CRUD services... which is fine...
A good resource on REST is REST in Practice
The main difference between SOAP and REST is that REST services does not have a WSDL defining the "operations", thank god for that. Yet the data structures can be defined by a schema language such as Schematron, XSD for XML...
REST stands for Representative State Transfer. It is built on the fact that the HTTP protocol is stateless, and specifies some methods like PUT/GET/POST etc. REST attaches semantics to those methods. For example, a GET means 'Read/Load'. PUT means 'save'. POST means 'update'. (I think I got that right...)
So REST is not a call to a URL, REST is a concept. You use REST by making calls to Urls. The difference between REST and a 'simple website' is the REST semantics. A PUT request means one thing, a GET request means another, etc.
RESTful webservices are language independent because the depend on the HTTP protocol; thats it. They don't depend on any language features, other than the ability to use the HTTP protocol.
REST returns structured XML or JSON data, you don't send back an entire webpage, which could be hard to interpret, and would be unnecessarily complicated.
You can parse XML or JSON data into an object in any language with a parser for this (including the .net languages). An object in this sense doesn't mean a full fledged .net object with a vtable etc.
SOAP overloads the POST data sent with an HTTP request, and hence instead of having many URLs to which you send individual requests, you just have one URL to which you post some XML data. In reality, the difference is mostly semantic.
I see APIs such as PayPal, etc. offering to call their services using NVP or SOAP/WSDL. When using a .NET environment (3.5) using traditional web services (no WCF) which is better and why? I know WSDL lets you drop in the API URL and it generates the wrappers for you. So then why do companies even offer NVP?
There seems to be never-ending confusion in this industry about the different types of web services.
SOAP is a messaging protocol. It has as much in common with REST as an apple has with a lawn tractor. Some of the things you want in a messaging protocol are:
Headers and other non-content "attributes."
Addressing - routing of a message to different servers/recipients based on the headers;
Guaranteed delivery via queuing and other methods;
Encryption, signing, and other security features;
Transactions and orchestrations;
Accurate representation of complex structured data in a single message;
...and so on. This is not an exhaustive list. What WSDL adds to SOAP, primarily, is:
Discoverability via a contract, a form of machine-readable "documentation" that tells consumers exactly what is required in order to send a message and allows proxies to be auto-generated;
Strict, automated schema validation of messages, the same way XSD works for XML.
REST is not a messaging protocol. REST is a system of resources and actions. It is a solid choice for many architectures for several important reasons as outlined by other answers. It also has little to no relevance to "NVP" services like PayPal and flickr.
PayPal's NVP API is not REST. It is an alternative, RPC-like messaging protocol over HTTP POST for clients that don't support or have difficulty supporting SOAP. This isn't my opinion, it's a statement of fact. One of the fields in the NVP is actually METHOD. This is clearly RPC verbiage. Take a look at their API for UpdateRecurringPaymentsProfile and try to tell me that this makes a lick of sense to describe as a "resource". It's not a resource, it's an operation.
In the case of PayPal specifically, the "NVP" (HTTP POST) API is inferior to the SOAP API in almost every way. It is there for consumers who can't use SOAP. If you can use it, you definitely should.
And I'm not necessarily bashing PayPal for this, either. I know a lot of folks have bashed them for not putting together a "proper" RESTful API but that is not what I am getting at. Not every service in the world can be accurately described with REST. PayPal isn't really a resource-based system, it's a transactional system, so I can forgive their architects and developers for not having a perfectly elegant REST architecture. It's debatable perhaps, but it's not black-and-white. It's fine; I'll just use the SOAP system if I need to.
Compare this to, say, the Twitter API. This is a true REST service. Every "operation" you can perform on this API is accurately described as either the retrieval or submission of a particular kind of resource. A resource is a tweet, a status, a user. In this case it literally makes no sense to use a complex SOAP API because you're not really sending messages, you're not performing transactions, you're just asking for specific things, and these things can be described with a single URL. The only difference is that instead of getting an HTML web page back, you're getting some XML or JSON data; the way you request it is exactly the same.
A REST Web Service usually (always?) uses HTTP GET for the retrieval of some resource. And Twitter does exactly this. GET still uses "Name-Value Pairs" - that's the query string, ?q=twitterapi&show_user=true. Those bits after the ? are name-value pairs. And here's a great example of why you would want to use REST over SOAP; you can hook this up to an RSS feed and get streaming updates. I can turn it into a Live Bookmark in Firefox. Or I can download it in JSON format and bind it to something like a jqGrid. The interesting thing is not that the request uses "Name-Value Pairs"; the interesting thing is that it's a simple URL and can be consumed by anything that knows how to request a web page.
So to try and summarize all of what I've said, think of it this way:
Use a REST API (if available) when you want to expose data, or consume or publish it, as a permanent resource.
Use a SOAP API when the system is transactional in nature and/or when you need the advanced features that a complex messaging protocol can offer, such as RM and addressing.
Use an RPC API (which includes just about any API that's modeled entirely around HTTP POST) when there is no SOAP API or when you are unable to use the SOAP API.
Hope that clears up some of the confusion.
I assume that by Name Value Pairs, you mean REST services.
The benefits to REST are primarily ease of development, simplicity and elegance, and lower overhead (which is very important if you are sending and receiving a lot of small messages).
Here are some of the advantages of REST:
REST is more lightweight
Human readable results
Everything is a URI addressable resource
REST services are more easily cached
REST is easier to build (no toolkits are required)
REST is easier to call (HTTP - GET, POST, PUT, DELETE)
NVP is HTTP POST
name=fred
amount=100
code=403
etc
This is the default format from any HTML browser so it's simple to implement for sending data to a web service
I don't think it's a good format for receiving data from web service? JSON or XML would be more suitable
No everyone uses VisualStudio, or has access to automatic wrapper generators, or wants to use such a beast
Many web mashups are coded in Javascript, so using HTTP POST to send data is the simplest way. The return result is a standard HTML response code (200, 403, 500, etc) and/or some JSON
Many service providers offer multiple API's to cater for all customers
I'd like to start moving our application business layers into a collection of REST web services. However, most of our Intranet has been built using Classic ASP and most of the developers where I work keep programming in Classic ASP. Ideally, then, for them to benefit from the advantages of a unique set of web APIs, it would have to be called from Classic ASP pages.
I haven't the slightest idea how to do that.
You could use a combination of JQuery with JSON calls to consume REST services from the client
or
if you need to interact with the REST services from the ASP layer you can use
MSXML2.ServerXMLHTTP
like:
Set HttpReq = Server.CreateObject("MSXML2.ServerXMLHTTP")
HttpReq.open "GET", "Rest_URI", False
HttpReq.send
#KP
You should actually use MSXML2.ServerXMLHTTP from ASP/server side applications. XMLHTTP should only be used client side because it uses WinInet which is not supported for use in server/service apps.
See http://support.microsoft.com/kb/290761, questions 3, 4 & 5 and
http://support.microsoft.com/kb/238425/.
This is quite important, otherwise you'll experience your web app hanging and all sorts of strange nonsense going on.
Here are a few articles describing how to call a web service from a class ASP page:
Integrating ASP.NET XML Web Services with 'Classic' ASP Applications
Consuming XML Web Services in Classic ASP
Consuming a WSDL Webservice from ASP
A number of the answers presented here appear to cover how ClassicASP can be used to consume web-services & REST calls.
In my opinion a tidier solution may be for your ClassicASP to just serve data in REST formats. Let your browser-based client code handle the 'mashup' if possible. You should be able to do this without incorporating any other ASP components.
So, here's how I would mockup shiny new REST support in ClassicASP:
provide a single ASP web page that acts as a landing pad
The landing pad will handle two parameters: verb and URL, plus a set of form contents
Use some kind of switch block inspect the URL and direct the verb (and form contents) to a relevant handler
The handler will then process the verb (PUT/POST/GET/DELETE) together with the form contents, returning a success/failure code plus data as appropriate.
Your landing pad will inspect the success/failure code and return the respective HTTP status plus any returned data
You would benefit from a support class that decodes/encodes the form data from/to JSON, since that will ease your client-side implementation (and potentially streamline the volume of data passed). See the conversation here at Any good libraries for parsing JSON in Classic ASP?
Lastly, at the client-side, provide a method that takes a Verb, Url and data payload. In the short-term the method will collate the parameters and forward them to your landing pad. In the longer term (once you switch away from Classic ASP) your method can send the data to the 'real' url.
Good luck...
Another possible solution is to write a .NET DLL that makes the calls and returns the results (maybe wrap something like RESTSharp - give it a simple API customized to your needs). Then you register the DLL as a COM DLL and use it in your ASP code via the CreateObject method.
I've done this for things like creating signed JWTs and salting and hashing passwords. It works nicely (while you work like crazy to rewrite the ASP).
Another possibility is to use the WinHttp COM object Using the WinHttpRequest COM Object.
WinHttp was designed to be used from server code.
All you need is an HTTP client. In .Net, WebRequest works well. For classic ASP, you will need a specific component like this one.