What is a restful web service and why do we need them
Hi,What is a restful web service and in which scenario do we need to use it
Regards,
RAJAN CRP
You must Sign In to post a response.
Category: WCF
What is a restful web service and in which scenario do we need to use it
Regards,
RAJAN CRP
#765230
First up all your need to know the above the web service. The main difference between the restful and and SOAP web service is accessing type from the client.
SOAP web service you have to refer the web service in to your project. you can access all the methods as like normal dll. Based on the parameters and return types you can set and get the data.
But Restful web service you do not need to refer the the web service in to your project. You can not access all the method as like dll. You have to make the simple HTTP call to the URL.
Write simple web service in both ways(SOAP and REST) that should return "HELLO"
Now copy the URL and past in your browser you can see the difference.
For SOAP your will not get the "HELLO" text which is return from the web service. But for RESTFUL you can get the "HELLO" text.
By Nathan
Direction is important than speed
SOAP web service you have to refer the web service in to your project. you can access all the methods as like normal dll. Based on the parameters and return types you can set and get the data.
But Restful web service you do not need to refer the the web service in to your project. You can not access all the method as like dll. You have to make the simple HTTP call to the URL.
Write simple web service in both ways(SOAP and REST) that should return "HELLO"
Now copy the URL and past in your browser you can see the difference.
For SOAP your will not get the "HELLO" text which is return from the web service. But for RESTFUL you can get the "HELLO" text.
By Nathan
Direction is important than speed
#765231
REST stands for Representational State Transfer. (It is sometimes spelled "ReST".) It relies on a stateless, client-server, cacheable communications protocol -- and in virtually all cases, the HTTP protocol is used. REST is an architecture style for designing networked applications
look at below link
http://stackoverflow.com/questions/671118/what-exactly-is-restful-programming
The REST services gives following flexibility, such as
- Uniform Interface
- Resource-Based
- Manipulation of Resources Through Representations
- Self-descriptive Messages
- Hypermedia as the Engine of Application State (HATEOAS)
- Stateless
- Cacheable
- Client-Server
- Layered System
- Code on Demand (optional)
Thanks
Koolprasd2003
Editor, DotNetSpider MVM
Microsoft MVP 2014 [ASP.NET/IIS]
look at below link
http://stackoverflow.com/questions/671118/what-exactly-is-restful-programming
The REST services gives following flexibility, such as
- Uniform Interface
- Resource-Based
- Manipulation of Resources Through Representations
- Self-descriptive Messages
- Hypermedia as the Engine of Application State (HATEOAS)
- Stateless
- Cacheable
- Client-Server
- Layered System
- Code on Demand (optional)
Thanks
Koolprasd2003
Editor, DotNetSpider MVM
Microsoft MVP 2014 [ASP.NET/IIS]
#766723
HI,
REST should be used if it is very important for you to minimize the coupling between client and server components in a distributed application.
This may be the case if your server is going to be used by many different clients that you do not have control over. It may also be the case if you want to be able to update the server regularly without needing to update the client software.
I can assure you that achieving this low level of coupling is not easy to do. It is critical to follow all of the constraints of REST to succeed. Maintaining a purely stateless connection is difficult. Picking the right media-types and squeezing your data into the formats is tricky. Creating your own media types can be even harder.
Adapting rich server behaviour into the uniform HTTP interface can be confusing and at times appears pedantic in comparison to the relatively straightforward RPC approach.
Despite the difficulties, the benefits are that you have a service that a client developer should be able to easily understand due to the consistent use of the HTTP protocol. The service should be easily discoverable due to hypermedia and the client should be extremely resilient to changes on the server.
The benefits of hypermedia and the avoidance of session state makes load balancing simple and service partitioning feasible. The strict conformance to HTTP rules make the availability of tools like debuggers and caching proxies wonderful thing.
REST should be used if it is very important for you to minimize the coupling between client and server components in a distributed application.
This may be the case if your server is going to be used by many different clients that you do not have control over. It may also be the case if you want to be able to update the server regularly without needing to update the client software.
I can assure you that achieving this low level of coupling is not easy to do. It is critical to follow all of the constraints of REST to succeed. Maintaining a purely stateless connection is difficult. Picking the right media-types and squeezing your data into the formats is tricky. Creating your own media types can be even harder.
Adapting rich server behaviour into the uniform HTTP interface can be confusing and at times appears pedantic in comparison to the relatively straightforward RPC approach.
Despite the difficulties, the benefits are that you have a service that a client developer should be able to easily understand due to the consistent use of the HTTP protocol. The service should be easily discoverable due to hypermedia and the client should be extremely resilient to changes on the server.
The benefits of hypermedia and the avoidance of session state makes load balancing simple and service partitioning feasible. The strict conformance to HTTP rules make the availability of tools like debuggers and caching proxies wonderful thing.
Return to Return to Discussion Forum