EEDC - Why use of REST for Web Services
•Download as PPTX, PDF•
1 like•516 views
Course: Execution Environments for Distributed Computing 2nd Presentation (5min): Why Use of REST for Web Services? Specific tasks: - Compare with SOAP - Convince people
Recommended
Recommended
More Related Content
Similar to EEDC - Why use of REST for Web Services
Similar to EEDC - Why use of REST for Web Services (20)
More from Maria Stylianou
More from Maria Stylianou (8)
Recently uploaded
Recently uploaded (20)
EEDC - Why use of REST for Web Services
- 1. Why Use of SOAP REST for Web Services ? Maria Stylianou – marsty5@gmail.com 34330 EEDC – Execution Environments in Distributed Computing
- 2. SOAP (Protocol) REST (Architecture) Rules, rules & rules Based on HTTP Looks like WWW NOT simple at all Easy XML format Simple Stateless Lightweight Too much overhead Lots of Representations 34330 EEDC – Execution Environments in Distributed Computing
- 3. SOAP (Protocol) REST (Architecture) Change on the service FLEXIBILITY Clients stop working Clients keep working POST to query/change GET to query data data Dangerous Safe Difficult to cache Cacheable & Scalable 34330 EEDC – Execution Environments in Distributed Computing
- 4. SOAP REST! 34330 EEDC – Execution Environments in Distributed Computing
- 5. SOAP REST! REST! BEST! 34330 EEDC – Execution Environments in Distributed Computing
Editor's Notes
- So, let’s say we have a web-service with the server responsible for is and some clients.SOAP: Simple Object Access ProtocolREST:Representational State Transfer1 SOAP (Simple Object Access Protocol) is a protocol, which defines rules that have to be valid for the messages to be sent between the server and the clients. This makes the Simple Object Access Protocol anything BUT simple!2 Like this wasn’t enough, these messages have to be in XML format and always wrapped in an envelop => That causes too much overhead.On the other hand, REST (Representational State Transfer) is an architecture based on HTTP. That’s why it looks like World Wide Web!That’s why it’s (a) EASY to build, (b) SIMPLE to understandand to use. It is also (c) LIGHTWEIGHT since it sends only HTTP requests using HTTP methods.Lastly (d) It can represent lots of different objects: XML, jpg, gif
- What’s more:SOAP is known for its inflexibility. One simple change to the service may lead to a total paralysis of the workers. Instead, the REAST is flexible and clients can “realize” the difference and keep working.Furthermore, SOAP uses POST to communicate with a service; to query or modify data. This may be dangerous as it’s more difficult to find if something goes wrong in an XML-formatted message. It is also difficult to cache a response for an XML message.REST, clients can send GET to request for some data. GET is not used for modification and therefore it offers safety! Additionally, it becomes scalable since it’s very easy to cache responses for GET requests!
- So,KEEP IT SIMPLEKEEP IT REST!
- So,KEEP IT SIMPLEKEEP IT REST!