Dịch vụ web và ứng dụng web

Question

Tôi biết đây là một câu hỏi cũ và phải được trả lời hàng trăm lần, nhưng tôi không thể tìm thấy câu trả lời thỏa đáng.

Tôi đang tạo một ứng dụng sẽ được các ứng dụng khác (di động/web) sử dụng để tìm nạp dữ liệu. Bây giờ tôi có 2 tùy chọn:

1. Tạo ứng dụng của tôi như một ứng dụng web đơn giản.
2. Tạo một dịch vụ web.

Dịch vụ web trông tinh vi hơn khi bất kỳ khách hàng nào cung cấp dữ liệu theo định dạng được chỉ định (SOAP/REST) ​​và ứng dụng của tôi sẽ phân tích yêu cầu và trả lại dữ liệu do khách hàng yêu cầu. Cách dữ liệu sẽ được sử dụng không phải là vấn đề của ứng dụng của tôi.

Câu hỏi của tôi là có thể đạt được điều tương tự bằng một ứng dụng web đơn giản chấp nhận yêu cầu ở định dạng XML và trả lời bằng phản hồi XML. Gut cảm giác là một dịch vụ web sẽ là một cách tốt hơn để đi cho loại hình dịch vụ mà chúng tôi không chắc chắn tất cả những người sẽ được sử dụng nó. Nhưng có lợi thế cụ thể nào khi sử dụng dịch vụ web trên ứng dụng web đơn giản không?

Answer 1

Ở cấp độ thấp, các ứng dụng web và dịch vụ web cũng giống như vậy. Cả hai đều hoạt động trên http (s). SOAP chỉ là một phiên bản được xác định rõ của XML. REST chỉ là HTTP. Nếu bạn muốn, bạn có thể làm cho một ứng dụng web trông giống như các dịch vụ web và ngược lại.

Sự khác biệt chính sẽ là các tùy chọn phát triển nội bộ dựa trên nền tảng bạn đang sử dụng. Nếu, ví dụ, bạn đang sử dụng Visual Studio sau đó thêm một ứng dụng dịch vụ WCF sẽ cung cấp cho bạn một dự án mà là theo mặc định hướng về WCF. Nhưng việc chọn bất kỳ loại ứng dụng nào khác sẽ không ngăn bạn thêm các dịch vụ Web.

Sử dụng SOAP nói chung là một lựa chọn tốt hơn so với xml cũ đồng bằng vì những lý do:

• Người dùng của bạn sẽ được mong đợi nó, và có thể sẽ biết làm thế nào để đọc nó rồi.

• Môi trường phát triển của người dùng của bạn có thể sẽ biết tất cả về SOAP và có thể diễn giải nó ra khỏi hộp. (Nếu bạn cung cấp tệp WSDL thì nhiều người dùng sẽ có thể sử dụng tập lệnh để tạo lớp học của bạn sau vài giây.)

• Thư của bạn có nhiều khả năng được xác định rõ hơn. Tôi đang làm việc trên một dự án tại thời điểm mà phía bên kia đã xác định cấu trúc XML ngẫu nhiên của riêng họ và đó là một cơn ác mộng để làm việc với. Tôi không bao giờ thực sự biết những gì mong đợi, và có rất ít sự nhất quán giữa các loại tin nhắn khác nhau của họ. Ít nhất nếu họ đã đồng ý tuân thủ SOAP thì tôi có thể đã có một thời gian dễ dàng hơn để giải thích thông điệp của họ.

Answer 2

Nếu ứng dụng của bạn không cần giao diện người dùng thì hãy biến nó thành dịch vụ web. Nếu nó cần một giao diện người dùng, sau đó sử dụng một ứng dụng web.

Answer 3

Câu hỏi của tôi cũng có thể đạt được bằng một ứng dụng web đơn giản chấp nhận yêu cầu ở định dạng XML và trả lời bằng phản hồi XML.

Đó là dịch vụ web. Tôi nghĩ đây là vấn đề về thuật ngữ.Bạn không có cách nào giải quyết vấn đề này ngoài việc sử dụng một dịch vụ web, cho dù đó là tùy thuộc vào bạn hay không, nhưng nếu bạn chuyển dữ liệu tới các máy khách ở định dạng XML, để đáp lại các yêu cầu XML, đó là một dịch vụ web.

Tôi nghi ngờ điều bạn muốn hỏi là bạn có nên sử dụng dịch vụ web RESTful hay phương pháp dựa trên SOAP phức tạp hay không. Đối với tôi câu trả lời phụ thuộc vào số lượng chức năng cần thiết trong 'Dịch vụ' của bạn.

SOAP

Nếu dịch vụ của bạn có nhiều chức năng hơn so với những người dùng của java và/hoặc visual studio muốn nhập khẩu tập tin WSDL của bạn và sử dụng dịch vụ của bạn như một đối tượng với tất cả các phân tích cú pháp XML làm cho họ , vì vậy SOAP sẽ là câu trả lời.

REST của

Nếu bạn chỉ có một vài chức năng, với rất cơ bản các thông số đầu vào và dữ liệu phản ứng, sau đó SOAP có thể là quá mức cần thiết.

MySite.com/Add/5/3 

hoặc

MySite.com/GetStockSymbol/Facebook 

hoặc

MySite.com/GetWeather/Paris/France 

Answer 4

Nếu chúng ta nghĩ rằng thuật ngữ, mà tôi nghĩ là câu hỏi chính ở đây.

Dịch vụ web đề cập đến phần mềm, phục vụ dữ liệu ở bất kỳ định dạng nào (XML/JSON, v.v.) thông qua một số loại giao diện web. Giao diện đó có thể được gọi là API (Giao diện lập trình ứng dụng). REST và SOAP là các cách để thiết kế API.

Ứng dụng là phần mềm đang sử dụng API này do dịch vụ web cung cấp.

Nói cách khác, dịch vụ web là "máy chủ" và ứng dụng là "ứng dụng khách". Thông thường máy chủ phục vụ máy móc và máy khách phục vụ người dùng. Vì vậy, theo bất kỳ cách nào bạn chọn để xây dựng hệ thống, tôi sẽ gọi phần phục vụ dữ liệu là "Dịch vụ Web" và phần sử dụng dữ liệu là "ứng dụng" (hoặc "ứng dụng web" nếu có).

Có vẻ như trong trường hợp của bạn, bạn đang xây dựng một dịch vụ web cung cấp dữ liệu định dạng XML cho nhiều ứng dụng. Vì vậy, câu trả lời của tôi là: xây dựng thứ bạn đang xây dựng và gọi nó là dịch vụ web.

Answer 5

Tôi biết nó quá muộn để phát lại, nhưng tôi vẫn muốn

Web tiếp cận dịch vụ là tốt nếu

a. tích hợp doanh nghiệp chỉ với các dịch vụ web, như tích hợp các mô-đun/ứng dụng phân tán.

b. phù hợp cho các ứng dụng được phân phối

c. nhiều hơn một người tiêu dùng cho cùng một dịch vụ - như Ngân hàng sử dụng dữ liệu từ Cơ quan báo cáo tín dụng

d. người tiêu dùng muốn dữ liệu ở các định dạng khác nhau - giống như một người tiêu dùng (khách hàng) muốn ở định dạng XML, khác sẽ là trong JASON ..vv

Answer 6

Tôi nghĩ rằng đây có thể giúp bạn trong việc giải quyết rắc rối của bạn

Có hai trường hợp sử dụng chính của WEB trong ngành công nghiệp

1. kinh doanh để tiêu dùng (B2C): Bất cứ khi nào có là nước tiêu thụ trực tiếp tương tác với doanh nghiệp vì nhu cầu của mình, chúng tôi luôn sử dụng ứng dụng web để cung cấp thông tin liên lạc giữa hai bên.
2. Business to Business (B2B): Có nghĩa là một phần của doanh nghiệp cần một số đầu vào/dịch vụ từ một phần khác của doanh nghiệp. Luôn có một Dịch vụ web được sử dụng để đáp ứng yêu cầu kinh doanh của doanh nghiệp. Thông thường, người tiêu dùng không bao giờ tương tác trực tiếp với Web-Services, chúng tôi chỉ tương tác với Ứng dụng web và Ứng dụng web tương tác với Dịch vụ web để biết thông tin/dữ liệu hoặc xử lý.

Taken từ http://coder2design.com/java-interview-questions/

Answer 7

Tôi hỏi câu hỏi này hơn 3 yeas trở lại và rất nhiều nước đã chảy dưới cầu kể từ đó. Tôi đã làm việc trên hàng chục ứng dụng web và tạo ra hàng trăm dịch vụ web. Vì vậy, tôi đoán nó có ý nghĩa để trả lời câu hỏi của riêng tôi ở đây.

Thách thức mà tôi phải đối mặt khi tôi hỏi câu hỏi này là tôi đã nhầm lẫn giữa các ứng dụng điều khoản và dịch vụ (lưu ý rằng web là yếu tố phổ biến trong ứng dụng web và dịch vụ web). Như tên sẽ đề nghị, ứng dụng là một ứng dụng trong chính nó, trong khi một dịch vụ có nghĩa là để phục vụ người khác. Một dịch vụ có thể không có ý nghĩa trừ khi ai đó sẽ sử dụng nó. Nó có thể phục vụ một hoặc nhiều ứng dụng hoặc dịch vụ.

Bây giờ nếu tôi nhìn vào câu hỏi của tôi

tôi đang tạo ra một ứng dụng mà sẽ được sử dụng bởi các ứng dụng khác (di động/web) để lấy dữ liệu. Bây giờ tôi có 2 tùy chọn, 1. để tạo ứng dụng của tôi dưới dạng ứng dụng web đơn giản 2. Để tạo một dịch vụ web.

Tôi muốn nói với bản thân rằng "Dude! Nếu có một thực thể có yêu cầu và trả về dữ liệu, bạn đang nói về một dịch vụ." Bởi vì tôi không lo lắng về những gì sẽ xảy ra với dữ liệu đó? Ai sẽ sử dụng nó? Làm thế nào sẽ được hiển thị?

Tôi đang thực hiện yêu cầu và trả lại dữ liệu. Bây giờ làm thế nào tôi làm điều đó là một phần của việc thực hiện. Tôi có thể sử dụng SOAP hoặc REST. Tôi có thể sử dụng Jersey hoặc Spring MVC/REST hoặc có thể là một servlet đơn giản có yêu cầu và trả về dữ liệu bằng JSON hoặc XML hoặc String hoặc bất kỳ định dạng bắt buộc nào khác.

Answer 8

Dịch vụ web không phải lúc nào cũng có giao diện người dùng. Chúng thường là API sử dụng JSON, cũng có thể là loại SOA sử dụng SOAP và XML chủ yếu, cũng có thể là ổ cắm, và máy chủ và các dịch vụ web vi mô khác, v.v.

Các ứng dụng web có thể được kết hợp với nhau theo nhiều cách. Có một số cách để tạo ứng dụng của bạn bằng cách phối hợp nhiều dịch vụ web và một gui riêng để kiểm soát chúng có liên quan đến các dịch vụ này.Cách khác mà không sử dụng dịch vụ là mã nhúng thủ tục vào ứng dụng giao diện người dùng của bạn, hoặc thậm chí tốt hơn, tạo một ứng dụng hướng đối tượng có các dịch vụ riêng của nó được chia sẻ trong Mô hình sau đó, quyền truy cập của bộ điều khiển và có chế độ xem riêng một GUI truy cập vào các dịch vụ ở mặt sau, hoặc thậm chí các ứng dụng phức tạp hơn, vượt qua các dịch vụ A2B, B2B, B2C từ một số GUI.

Dịch vụ không phải lúc nào cũng có GUI, họ có thể có CRUD để duy trì dữ liệu, nhưng một khi bạn bắt đầu có các loại tính năng này, nó sẽ trở thành một ứng dụng theo đúng nghĩa của nó. Các dịch vụ được áp dụng cho một cái gì đó lớn hơn bản thân họ. ứng dụng này tạo ứng dụng của bạn. Nó phải có một mục đích. Thông thường phải mất nhiều hơn một dịch vụ mù để hoàn thành applicatoin của bạn, và có một số loại giao diện.

Nếu bạn chỉ một cách mù quáng gửi yêu cầu uri đến dịch vụ của bạn, và nó sẽ gửi lại một cách mù quáng, đó là một dịch vụ. Whats gửi một cách mù quáng? Nếu bạn, thì không phải là một ứng dụng. Nếu một số loại crud, sau đó nó trở thành một ứng dụng, crud là một GUI để truy cập các dịch vụ, và nói chung, một hệ thống ứng dụng quản lý dữ liệu của nó. Bây giờ nếu bạn đặt một lớp ở mặt trước để chứng minh dữ liệu này theo kiểu trang web, bây giờ bạn có một sản phẩm để hiển thị dữ liệu này, một sản phẩm để quản lý dữ liệu và dữ liệu là sản phẩm thực và có thể truy cập thông qua dịch vụ web , nó bây giờ là một ứng dụng đầy đủ. Nỗ lực của bạn trong việc tạo ra điều này sẽ trở thành ứng dụng của bạn.

Answer 9

Từ Dịch vụ RESTful Web bởi Leonard Richardson và Sam Ruby, ISBN: 978-0-596-52926-0:

dịch vụ Web là thực sự rất giống với các ứng dụng web, nhưng việc tạo ra nguồn là một trong những nơi chúng khác nhau. Sự khác biệt chính ở đây là các biểu mẫu HTML hiện chỉ hỗ trợ GET và POST. Điều này có nghĩa là các ứng dụng web phải sử dụng POST quá tải để truyền tải bất kỳ hoạt động không an toàn nào.