Endpoint Là Gì

     

Có phải bạn là một trong developer mới, chúng ta thấy những developer tay nghề cao khác nói với nhau về restful. Bạn lần khần restful là gì nên các bạn lên google search “restful là gì?”. Bạn đọc khá nhiều nội dung bài viết rồi nhưng vẫn còn đó mông lung chưa biết mặt mũi thằng restful chũm nào? nếu như khách hàng đang cảm thấy như vậy, thì nên đọc nội dung bài viết này của mình nhé.Bạn vẫn xem: Endpoint là gì

Bài viết này bản thân sẽ trình diễn những vẫn đề bao quanh restful api trước khi mình trình bày cụ thể về nó, thế cho nên bạn hãy kiên trì đọc nhé.

Bạn đang xem: Endpoint là gì

Mục lục

I. Web service là gì?II. Khám phá về RESTfulIII. API là gì cùng RESTful API là gì?

I. Website service là gì?

Website thì ai cũng cũng biết rồi, như blog tubepphuonghai.com này đó là một website đó. Thế nhưng web service thì khác, không phải ai ai cũng có thời cơ được nghe thấy nhiều từ này kể từ thời điểm mà Restful trở yêu cầu phổ biến.

Web service cũng là 1 trong những ứng dụng web hoạt động tương tự như một website, tức là để truy cập vào web service bạn có thể mở trình chú ý lên, gõ vào thanh địa chỉ url của website service đó. Tuy vậy khác với trang web – website để cho người đọc, thì web service sinh ra để cho các cỗ máy, hoặc những ứng dụng khác đọc.

1.1. Vì sao web service ra đời?

Câu chuyện kể rằng tất cả 2 anh bạn tên Quang với tên Bình nghịch thân với nhau từ bỏ hồi nhỏ. Phệ lên, quang quẻ mở một công ty giới thiệu việc khiến cho nhân sự IT, Bình thì mở một công ty huấn luyện nhân sự IT. Một hôm, quang đãng nói với Bình “mày ơi, doanh nghiệp tao gồm mấy job PHP lương cao lắm, mày để quảng cáo cho tao vào mấy khóa học về PHP của dòng sản phẩm nhé“, Bình nghe vậy liền đồng ý luôn, vì chưng tốt cho tất cả hai mà. Nhưng sự việc là website tuyển dụng của Quang cùng website đào tạo của Bình chạy sinh sống trên 2 nhỏ server không giống nhau, không tồn tại một “cây cầu” nào kết nối giữa nhị website này cả.

Quang nghĩ đến giải pháp sẽ chèn “cứng” quảng cáo của mình trong những khóa học của Bình, cơ mà Bình gạt đi. Vị chèn cứng như vậy, lỡ job PHP của Quang quá hạn sử dụng tuyển dụng thì sao, lại gỡ xuống à? mà một job thì không sao, chứ 100 job thì chỉ có chèn lên cùng với gỡ xuống cũng hết ngày. Bình bèn nghĩ ra bí quyết này và bảo Quang, “bên website tuyển dụng của mày, mày tạo nên tao một trang riêng rẽ chỉ hiển thị những job PHP nhưng mà mày ý muốn quảng cáo, bên website của tao vẫn đọc nội dung trang web này rồi hiển thị lên“.

Vậy là Quang chế tạo một website riêng đến Bình ở địa chỉ cửa hàng http://webtuyendungit.com/job-php, khi truy vấn vào đây sẽ chỉ nhận thấy nội dung khó hiểu như sau

"jobs": Sau đó, Bình áp dụng CURL để mang nội dung trên website của Quang, so với thành tài liệu và hiển thị ngon lành lên website đào tạo và huấn luyện của mình. Giờ đây Quang muốn chuyển đổi nội dung quảng bá thì chỉ cần biến hóa nội dung của trang web trên, vô cùng tiện nghi và công ty động.

Trên đó là một ví dụ điển của website service. Khi các ứng dụng không liên quan tới nhau, nhưng mà vẫn ước ao trao đổi dữ liệu với nhau thì bạn ta đã nghĩ tức thì tới việc áp dụng web service. Một web service đang trả về dữ liệu theo một kết cấu nào đó (XML hoặc JSON,…) để những ứng dụng khác rất có thể đọc, đối chiếu và thực hiện được. Như ví dụ trên thì http://webtuyendungit.com/job-php chính là endpoint của một website service.

Web service ra đời như là 1 điều hiển nhiên, bởi vì ngày càng có không ít hệ thống chạy đa căn cơ như Facebook, Youtube,.. Ra đời. Đặc điểm của các hệ thống chạy đa căn cơ này là luôn yêu ước khả năng đồng bộ dữ liệu. Ví dụ như bạn like một status facebook trên web, thì trên phầm mềm cũng bắt buộc được thể hiện, chúng ta đăng một bức ảnh lên facebook từ bỏ mobile, thì trên web cũng yêu cầu nhìn thấy. Để có tác dụng được điều này, bạn ta sẽ tạo nên ra một bé web service, để khi chúng ta đăng ảnh, like hay thực hiện ngẫu nhiên hành rượu cồn gì đều yêu cầu gọi cho tới web service này cho dù hành động đó được tiến hành từ web giỏi mobile. Phương diện khác, vận dụng web cùng mobile sẽ kết nối vào bình thường web service để đọc dữ liệu, vì vậy sẽ bảo đảm được tài liệu là giống như nhau cho dù trên các nền tảng khác nhau.

Tóm lại website service thành lập và hoạt động nhằm xử lý một vụ việc sau

Giúp các hệ thống không tương quan tới nhau vẫn rất có thể giao tiếp được cùng với nhauĐồng bộ tài liệu giữa các nền tảng
*

Web service nằm giữa1.2 Endpoint của website service

Mỗi URL kèm HTTP method của web service thì được gọi là một trong endpoint, như lấy một ví dụ trên thì mình gồm http://webtuyendungit.com/job-phpchính là một trong endpoint. Khi làm một endpoint mang đến web service, bạn sẽ phải quan tâm tới một trong những vấn đề sau:

Endpoint sử dụng cấu trúc dữ liệu nào nhằm trả về?

XML hoặc JSON là nhì lựa chọn cho chính mình để áp dụng làm tài liệu trả về mang lại endpoint. Như lấy ví dụ như trên là mình áp dụng JSON.

URL được viết như thế nào?

Ví dụ mình có một endpoint trả về thông tin chi tiết của một user dựa vào ID của user được gởi lên, thì mình có thể lựa lựa chọn 1 trong hai bí quyết viết sau (giả sử ID của user là 1).

http://webservice.com/users?id=1http://webservice.com/users/1

Hoặc chúng ta có thể dùng một bí quyết viết không giống cũng được, nói tầm thường là endpoint được viết ra làm sao là vì bạn, không tồn tại quy tắc bình thường nào cho phương pháp viết endpoint cả.

URL áp dụng HTTP Method nào?

Giả sử mình chọn URL gồm dạng là http://webservice.com/users?id=1, thế HTTP method là gì được nhỉ? GET tốt POST? Câu vấn đáp cũng là tùy bạn, GET giỏi POST cũng được, không có quy tắc nào cả.

An toàn dữ liệu

Web service trao đổi dữ liệu với những ứng dụng không giống thông qua môi trường xung quanh mạng. Nếu nhằm lộ những endpoint, thì kỹ năng cao dữ liệu trả về trong số endpoint đó cũng trở nên lộ. Thực tế đã có khá nhiều vụ lộ thông tin người tiêu dùng mà vì sao là do những endpoint yếu bảo mật.

1.3 các loại website service

Các endpoint của website service vượt “tự do”, tài liệu trả về, bí quyết viết url, http method phần đông do chúng ta tự quyết định. Nhận thấy điều này chưa phù hợp lý, nên người ta giới thiệu hai loại chuẩn chỉnh cho web service như sau:

SOAP website service

Simple Object Access Protocol là 1 trong những dạng giao thức (cũng có thể coi là một chuẩn). SOAP áp dụng XML làm kết cấu dữ liệu trả về. Tuy nhiên SOAP không có quy ước về kiểu cách viết url cũng giống như http method. Nhưng bù lại, SOAP lại sở hữu WS-SecuritySOAP – là một chuẩn chỉnh giúp bình an dữ liệu, xử lý được sự việc an toàn dữ liệu mà mình kể ở trên.

RESTful website service

REpresentational State Transfer, là một chuẩn của website service. RESTful rất có thể sử dụng JSON, XML, plain text, html,.. Làm cấu tạo dữ liệu trả về, tất cả quy ước cụ thể về cách viết url và http method. Dẫu vậy RESTful không hỗ trợ cơ chế bảo đảm thông tin trong những endpoint như SOAP. Tuy nhiên bạn có thể sử dụng Json website Token kết hợp với RESTful để giải quyết vấn đề này, đề xuất việc không có sẵn cơ chế bình an thông tin chưa phải là điều đáng lo sợ khi thực hiện RESTful.

SOAP vs RESTful

Ngày nay những dự án web service đa số (thậm chí gần như tất cả) đều thực hiện RESTful cố gắng vì sử dụng SOAP. Bởi như mình nhắc ra nghỉ ngơi trên thì chúng ta thấy RESTful tất cả quy ước rõ ràng hơn hẳn SOAP. Ngoài ra RESTful hoàn toàn có thể sử dụng nhiều loại dữ liệu để trả về, trong đó có cả XML, vậy xét ở góc nhìn nào đó có thể nói rằng rằng RESTful bao gồm cả SOAP cũng không sai.

Tuy nhiên SOAP vẫn còn đấy được sử dụng trong không ít dự án cũ cần phải bảo trì, nên chúng ta mà khám phá được SOAP nữa thì sẽ càng tốt.

II. Khám phá về RESTful

Sau đây new thật sự là phần đông gì bạn có nhu cầu tìm đọc về RESTful nhé.

Xem thêm: Liệu Bạn Đã Biết: Máy Ảnh Dslr Là Gì ? Và Nó Khác Mirrorless Như Thế Nào

RESTful có hệ thống quy tắc nghiêm ngặt về những viết endpoint cùng HTTP method, mình đang tóm tắt một vài ba nguyên tắc đặc trưng làm đề xuất “tên tuổi” của RESTful để chúng ta tiện theo dõi.

2.1 nguyên tắc về HTTP method của endpoint

Nếu là web developer, chắc chắn rằng bạn biết đến method GET với POST. Tuy nhiên với RESTful thì gồm thêm một số trong những method mới, kèm giải pháp sử dụng tương ứng như sau:

GET: được sử dụng để lấy thông tin từ sever theo URI sẽ cung cấp.POST: gửi tin tức tới máy chủ thông qua các biểu mẫu mã http (đăng kí chả hạn..)HEAD: giống với GET dẫu vậy response trả về không tồn tại body, chỉ tất cả headerPUT: ghi đè tất cả thông tin của đối tượng người sử dụng với hồ hết gì được nhờ cất hộ lênPATCH: ghi đè những thông tin được thay đổi của đối tượng.DELETE: xóa khoáng sản trên server.CONNECT: thiết lập cấu hình một liên kết tới server theo URI.OPTIONS: mô tả những tùy chọn tiếp xúc cho resource.TRACE: tiến hành một bài xích test loop – back theo đường dẫn đến resource.

Thực tế thì mình bắt đầu chỉ thao tác làm việc với những method GET, POST, PUT, DELETE thôi, những method còn lại thì chưa làm bao giờ, mà lại tương lai chắc chắn rằng sẽ chạm chán :p.

2.2 Quy mong về resource, endpoint

Resource có nghĩa là tài nguyên, nhưng đấy là một có mang được nói tới nhiều trong RESTful, nên mình sẽ không thay đổi từ khoá này mà lại không Việt hóa nhé.

Resource đó là dữ liệu mà họ phải quản ngại lý, có thể là customers, products, posts, images, videos… phương diện khác, thương hiệu resource cũng trở nên xuất hiện tại trong biện pháp viết endpoint, nên nếu như khách hàng đặt tên cho resource một giải pháp khoa học, thì endpoint cũng trở nên dễ hiểu và dễ tiếp cận hơn.

Xem ví dụ như trong bảng sau để hiểu rõ đâu là resource, cùng resource hay được viết ra sao trong mỗi endpoint

EndpointResource
http://api.example.com/usersusers
http://api.example.com/users/1/accountsaccounts
http://api.example.com/users/1/imagesimages

Dưới đây là một vài ba quy tắc để bạn tham khảo về phương pháp đặt thương hiệu resource làm thế nào để cho hay.

Sử dụng danh từ để đặt tên đến resource

RESTful tổ chức triển khai resource bên dưới dạng các đối tượng, do vậy resource nên chọn cái tên dưới dạng dạng một danh từ bỏ chứ không phải một hễ từ. Giả sử bản thân có một vài resource là: users, posts, thì resource tương ứng sẽ được viết trong các endpoint như sau:

http://api.example.com/users # Liệt kê tất cả userhttp://api.example.com/users/1 # cụ thể user tất cả ID là 1http://api.example.com/posts # Liệt kê toàn bộ posthttp://api.example.com/posts/1 # cụ thể post tất cả ID là 1Sử dụng đấu sượt (/) nhằm thể hiện quan hệ phân cung cấp giữa những resources

Trong thực tế, những resource thường xuyên có quan hệ với nhau. Ví dụ như mình tất cả resource user, từng user lại có không ít resource image. Thì minh hoàn toàn có thể thiết kế những endpoint như sau

http://api.example.com/users # Liệt kê toàn bộ usershttp://api.example.com/users/1 # cụ thể user có ID là 1http://api.example.com/users/1/images # Liệt kê tất cả images của user bao gồm ID là 1Dùng vệt gạch ngang (-) để phân cách giữa các cụm từ

http://api.example.com/banned-users # giỏi (1)http://api.example.com/banned_users # Không tốt (2)http://api.example.com/bannedUsers # Không tốt (3)Trong ví dụ như trên, bí quyết (1) và (2) rõ ràng là dễ nhìn đọc hơn các so với phương pháp (3). Một số bạn theo nhà chương của camelcase rất có thể sẽ thấy cách (3) dễ đọc hơn. Tuy nhiên nếu mình có caiTenDaiNgoangNgoang chũm này thì rõ ràng khó quan sát hơn cai-ten-dai-ngoang-ngoang gắng này đúng không.

Vậy nguyên nhân (1) lại giỏi hơn (2)? lý do là dâu gạch dưới (_) bị phụ thuộc nhiều vào font text hiển thị, trong một số trong những trường thích hợp nó hoàn toàn có thể bị che mất một phần, hoặc bị xóa, hoặc bị gửi thành dấu cách trên một vài trình duyệt. Điều này dễ ợt gây ra nhầm lẫn cho những người sử dụng.

Sử dụng chữ hay cho toàn thể endpoint

http://api.example.com/banned-users # giỏi (1)HTTP://API.WEBSERVICE.COM/banned-users # Không tốt (2)http://api.example.com/BANNED-USERS # Không tốt (3)Trong từng endpoint, ngoài phần giao thức với phần domain, thì những phần sót lại sẽ sáng tỏ chữ hoa chữ thường. Có nghĩa là ta bao gồm endpoint (1) sẽ tương tự với endpoint (2), cơ mà endpoint (3) thì khác hoàn toàn.

Vậy để đồng bộ và tránh nhầm lẫn, bọn họ nên viết những endpoint bằng văn bản thường.

Không áp dụng đuôi mở rộng cho các endpoint

http://api.example.com/banned-users # xuất sắc (1)http://api.example.com/banned-users.json # không giỏi (2)http://api.example.com/banned-users.xml # không tốt (3)Đuôi mở rộng chính là .json và .xml trong endpoint (2) với (3) sinh sống ví dụ trên. Một số chúng ta cũng có thể thấy rằng bởi vậy là tường minh hơn, rằng khi tôi truyền .json tức thị tôi hy vọng lấy tài liệu dạng json và giống như với xml. Tuy nhiên làm như vậy chưa phải là bí quyết hay vì:

Endpoint dài hơn nữa và nhìn dường như xấu xíBạn đã phải gia hạn nhiều endpoint hơn

Nếu như bạn vẫn mong muốn endpoint có thể trả về nhiều kiểu tài liệu khác nhau, thì chúng ta cũng có thể sử dụng nằm trong tính Content-Type của request header để khẳng định kiểu tài liệu trả về.

Sử dụng query params để lọc kết quả

Giả sử mình gồm một endpoint /users để mang ra danh sách toàn thể users. Nhưng thực tế mình chỉ muốn kéo ra các users nghỉ ngơi Việt Nam. Một số các bạn sẽ nghĩ đến cách tạo một endpoint như mẫu mã như /users/vn để xử lý yêu mong này. Tuy vậy bạn không nhất thiết phải làm thế, chúng ta có thể coi Việt Nam như một tiêu chuẩn để lọc, và endpoint đề nghị được viết như vậy này

http://api.example.com/users?country=vn # tốt. Sử dụng query params countryhttp://api.example.com/users/vn # không tốtBạn cũng nên thực hiện query params nhằm phân trang hoặc chuẩn bị xếp tác dụng thay bởi việc kiến tạo một endpoint mới

http://api.example.com/users?page=1 # Tốthttp://api.example.com/users/pages/1 # không tốthttp://api.example.com/users?orderBy=latest # Tốthttp://api.example.com/users/orderBy/latest # không tốthttp://api.example.com/users/orderBy?latest # không tốtSử dụng HTTP method để bộc lộ CRUD

Bạn tránh việc thể hiện các làm việc với resource bằng việc chỉ ra bên trên URI, núm vào đó bạn hãy sử dụng những HTTP method tương ứng.

# Liệt kê danh sách usersHTTP GET http://api.example.com/users # NênHTTP GET http://api.example.com/users/all # không nên# thêm một users mới vào danh sáchHTTP POST http://api.example.com/users # NênHTTP POST http://api.example.com/users/create # không nênHTTP POST http://api.example.com/users/store # không nên# update thông tin user có ID là 1HTTP PUT http://api.example.com/users/1 # NênHTTP POST http://api.example.com/users/1/update # không nênHTTP POST http://api.example.com/users/1/edit # ko nên# Xóa user có ID là 1HTTP DELETE http://api.example.com/users/1 # NênHTTP POST http://api.example.com/users/1/destroy # không nênHTTP POST http://api.example.com/users/1/delete # không nên2.3 tất cả nhất thiết phải tuân theo 100% chuẩn chỉnh RESTful không?Thực tế bản thân trải qua các dự án thực hiện RESTful thì chưa có dự án nào triển khai được 100% chuẩn của RESTful, bởi

Đa phần những developer chỉ thích sử dụng method POST cùng GET cho 1-1 giảnMột số chủ ý cho rằng /users/1 khó áp dụng hơn /users?id=1

Vậy gồm nhất thiết là phải chuẩn 100% RESTful không? Câu trả lời là không, chuẩn của RESTful là một trong chuyện cơ mà nó cũng phải phù hợp với sự thống nhất của team, cân xứng với tính chất của dự án. Tuy nhiên quan điểm của chính mình là càng chuẩn chỉnh RESTful thì càng tốt.

III. API là gì và RESTful API là gì?

3.1. API là gì?

API là viết tắt của Application Programing Interface – đồ họa lập trình ứng dụng. đồ họa ở đây không phải là đồ họa của phần mềm, không phải là phần đa khối màu, bố cục tổng quan của phần mềm mà mắt bạn nhìn thấy đâu nhé. Bối cảnh ở đây y như một chuẩn chung để liên kết vậy. Ví như cái ổ cắn với mẫu phích cắm, tuy nhiên chúng rất có thể đến từ hai bên sản xuất khác biệt nhưng khi cắn vào nhau thì bọn chúng vẫn vừa khít, đấy là do bọn chúng cùng tuân theo một hình ảnh kết nối.

Vì một trong những phần mềm chứa rất nhiều logic phức tạp, nên người ta tìm cách chia nhỏ dại nó ra thành các phần, mỗi phần này lâm thời gọi là một component. Mỗi component sẽ sở hữu được tính chủ quyền cao, ít phụ thuộc hoặc có thể không phục nằm trong vào những thành phần khác. Tuy là gồm tính độc lập cao, nhưng mà để có thể kết nối được với nhau mà một trong những phần mềm hoàn chỉnh, buộc chúng vẫn cần tuân theo một hoặc một số chuẩn chỉnh nào đó. Thì mỗi cái chuẩn chỉnh đó được gọi là 1 giao diện lập trình ứng dụng – hay chính là một API.

3.2 RESTful API là gì?

RESTful API là đông đảo API của web service thực hiện theo chuẩn RESTful. Trước lúc áp dụng RESTful để tạo API, người ta sẽ đưa ra các chuẩn (API) trước. Ví dụ như mình qui định nếu triển khai thêm users thành công, thì sẽ bắt buộc trả về header status là 200, kèm một tin nhắn có nội dung là “thành công” chẳng hạn, ai nhưng làm sai theo phép tắc này tức là sai API, và endpoint đó sẽ chỉ được xem là RESTful endpoint chứ không hề được xem là RESTful API.

IV. Lời kết

Kết luận lại, bài viết này mình thích bạn lưu một số trong những ý bao gồm sau:

RESTful chỉ với một chuẩn của web service, mong biết về RESTful thì phải tìm hiểu về website service trước.RESTful ko khó, nó chỉ là một tập các quy tắc thôi, tuân theo luật lệ này tức là bạn đã làm được RESTful

Bạn nên làm những gì tiếp theo?

Nếu bạn đã từng thao tác với RESTful rồi, chúng ta đọc nội dung bài viết này chỉ để củng núm thêm kỹ năng thì mình hy vọng bạn vẫn hiểu hơn về nó qua cách phân tích và lý giải của mình. Còn nếu bạn chưa từng làm việc với RESTful, hoặc đây là lần đầu tiên bạn nghe thấy quan niệm này, thì bạn nên làm một test web service nhỏ tuổi áp dụng RESTful để hiểu hơn nhé, chứ có giải thích hay rứa nào thì nội dung bài viết này của mình cũng chỉ là lý thuyết mà thôi.

Xem thêm: Khối Lượng Muối Khan Nghĩa Là Gì ? Kí Hiệu Hóa Học Của Muối Bài Tập Tính Toán Tìm Khối Lượng Muối Khan

Bài viết được viết dựa trên kinh nghiệm tay nghề làm việc của chính mình và tham khảo một trong những nguồn. Xin nhận phần đa gạch đá.

Tài liệu tham khảo: https://restfulapi.net

(*) CURL: là cỗ thư viện được sử dụng sẽ giúp đỡ thực hiện câu hỏi chuyển dữ liệu thông qua nhiều giao thức không giống nhau như HTTP, FPT…