Có yêu cầu bạn là 1 trong developer mới, chúng ta thấy những developer lành nghề khác nói với nhau về restful. Bạn do dự restful là gì nên chúng ta lên google tìm kiếm “restful là gì?”. Bạn đọc khá nhiều 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 thế nào? nếu như bạn đang cảm thấy như vậy, thì nên đọc bài viết này của mình nhé.Bạn sẽ xem: Endpoint là gì

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

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

Mục lục

I. Website service là gì?II. Tìm hiểu về RESTfulIII. API là gì với RESTful API là gì?

I. Website service là gì?

Website thì ai cũng cũng biết rồi, như blog love-ninjas.com này đó là một website đó. Mặc dù thế web service thì khác, ko phải người nào cũng có cơ hội được nghe thấy cụm 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 ứng dụng web hoạt động tương tự như một website, tức là để truy cập vào website service bạn có thể mở trình coi ngó lên, gõ vào thanh địa chỉ url của web service đó. Tuy nhiên khác với trang web – web để cho tất cả những người đọc, thì web service sinh ra làm 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 đứa bạn tên Quang với tên Bình chơi thân cùng với nhau từ hồi nhỏ. Mập lên, quang đãng mở một công ty ra mắt việc khiến cho nhân sự IT, Bình thì mở một công ty huấn luyện và giảng dạy nhân sự IT. Một hôm, quang nói cùng với Bình “mày ơi, doanh nghiệp tao bao gồm mấy job PHP lương cao lắm, mày đặt quảng cáo mang lại tao vào mấy khóa huấn luyện về PHP của sản phẩm nhé“, Bình nghe vậy liền đồng ý luôn, do tốt cho cả hai mà. Nhưng vụ việc là website tuyển dụng của Quang với website huấn luyện của Bình chạy ngơi nghỉ trên 2 nhỏ server khác nhau, không tồn tại một “cây cầu” nào liên kết giữa nhì website này cả.

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

Vậy là Quang chế tác một website riêng mang đến Bình ở add http://webtuyendungit.com/job-php, khi truy vấn vào đây vẫn chỉ bắt gặp nội dung cạnh tranh hiểu như sau

"jobs": Sau đó, Bình áp dụng CURL để đưa nội dung bên 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à giảng dạy của mình. Bây giờ Quang muốn biến hóa nội dung lăng xê thì chỉ cần thay đổi nội dung của website trên, vô cùng tiện lợi và nhà động.

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

Web service thành lập và hoạt động như là 1 trong điều hiển nhiên, chính vì ngày càng có nhiều hệ thống chạy đa căn nguyên 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 luôn yêu mong khả năng đồng hóa dữ liệu. Ví dụ bạn lượt thích một status facebook bên trên web, thì trên tiện ích cũng đề nghị được thể hiện, chúng ta đăng một bức hình ảnh lên facebook trường đoản cú mobile, thì bên trên web cũng đề nghị nhìn thấy. Để làm được điều này, người ta sẽ tạo nên ra một nhỏ web service, để khi bạn đăng ảnh, like hay thực hiện ngẫu nhiên hành hễ gì đều buộc phải gọi cho tới web service này cho dù hành vi đó được triển khai từ web xuất xắc mobile. Phương diện khác, ứng dụng web với mobile sẽ liên kết vào tầm thường web service để đọc dữ liệu, vì vậy sẽ đảm bảo an toàn được tài liệu là kiểu như nhau cho dù trên những nền tảng không giống nhau.

Tóm lại website service thành lập nhằm giải quyết và xử lý một vấn đề sau

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

Web service ở giữa1.2 Endpoint của web service

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

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

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

URL được viết như vậy nào?

Ví dụ mình có một endpoint trả về thông tin chi tiết của một user nhờ vào ID của user được gởi lên, thì mình hoàn toàn có thể lựa lựa chọn 1 trong hai biện pháp 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ác cũng được, nói phổ biến là endpoint được viết ra làm sao là bởi vì bạn, không tồn tại quy tắc bình thường nào cho biện pháp viết endpoint cả.

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

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

An toàn dữ liệu

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

1.3 những loại website service

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

SOAP web service

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

RESTful website service

REpresentational State Transfer, là một chuẩn chỉnh của web service. RESTful hoàn toàn có thể sử dụng JSON, XML, plain text, html,.. Làm kết cấu dữ liệu trả về, tất cả quy ước rõ ràng về biện pháp viết url cùng http method. Tuy vậy RESTful không hỗ trợ cơ chế bảo vệ thông tin trong các endpoint như SOAP. Mặc dù nhiên chúng ta cũng có thể sử dụng Json website Token kết phù hợp với RESTful để xử lý vấn đề này, buộc phải việc không tồn tại sẵn cơ chế bình an thông tin chưa hẳn là điều đáng thấp thỏm khi thực hiện RESTful.

SOAP vs RESTful

Ngày nay những dự án web service phần nhiều (thậm chí gần như là tất cả) đều thực hiện RESTful cầm vì áp dụng SOAP. Vị như mình nói ra làm việc trên thì chúng ta thấy RESTful bao gồm quy ước ví dụ hơn hẳn SOAP. Ngoài ra RESTful hoàn toàn có thể sử dụng những 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 RESTful bao hàm cả SOAP cũng ko sai.

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

II. Mày mò về RESTful

Sau đây new thật sự là các gì bạn muốn tìm hiểu về RESTful nhé.

RESTful có khối hệ thống quy tắc nghiêm ngặt về những viết endpoint cùng HTTP method, mình sẽ tóm tắt một vài nguyên tắc quan trọng đặc biệt làm phải “tên tuổi” của RESTful để chúng ta tiện theo dõi.

2.1 quy tắc về HTTP method của endpoint

Nếu là website developer, chắc chắn bạn nghe biết method GET cùng POST. Tuy nhiên với RESTful thì tất cả thêm một số method mới, kèm biện 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 thông tin tới sever thông qua các biểu mẫu mã http (đăng kí chả hạn..)HEAD: giống như với GET tuy vậy response trả về không tồn tại body, chỉ gồm headerPUT: ghi đè toàn bộ thông tin của đối tượng với phần đa gì được giữ hộ lênPATCH: ghi đè các 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 một liên kết tới vps theo URI.OPTIONS: tế bào tả những tùy chọn tiếp xúc cho resource.TRACE: tiến hành một bài bác test loop – back theo đường truyền đến resource.

Thực tế thì mình new chỉ làm việc với những method GET, POST, PUT, DELETE thôi, các method sót lại thì chưa làm bao giờ, mà lại tương lai chắc hẳn rằng sẽ gặp mặt :p.

2.2 Quy cầu về resource, endpoint

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

Resource chính là dữ liệu mà họ phải quản lý, rất có thể là customers, products, posts, images, videos… khía cạnh khác, tên resource cũng trở thành 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 mang đến resource một cách khoa học, thì endpoint cũng trở nên dễ hiểu và dễ tiếp cận hơn.

Xem ví dụ trong bảng sau để hiểu rõ đâu là resource, và resource thường xuyên được viết thế nào trong từng endpoint

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

Dưới đó là một vài ba quy tắc để bạn xem thêm về bí quyết đặt thương hiệu resource làm thế nào để cho hay.

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

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

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

Trong thực tế, những resource hay 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 rất 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 gồm ID là 1http://api.example.com/users/1/images # Liệt kê toàn bộ images của user bao gồm ID là 1Dùng lốt gạch ngang (-) để phân cách giữa những cụm từ

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

Vậy tại sao (1) lại xuất sắc hơn (2)? vì sao là dâu gạch dưới (_) bị phụ thuộc vào nhiều vào font text hiển thị, trong một trong những trường đúng theo nó hoàn toàn có thể bị bịt mất một phần, hoặc bị xóa, hoặc bị đưa thành dấu cách trên một trong những trình duyệt. Điều này dễ dãi 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 giỏi (3)Trong từng endpoint, xung quanh phần giao thức với phần domain, thì các phần sót lại sẽ minh bạch chữ hoa chữ thường. Tức là ta tất cả endpoint (1) sẽ tương tự với endpoint (2), cơ mà endpoint (3) thì khác trả toàn.

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

Không thực hiện đuôi không ngừng mở rộng cho những endpoint

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

Endpoint dài ra hơn và nhìn có vẻ xấu xíBạn đang phải duy trì nhiều endpoint hơn

Nếu như bạn vẫn ý muốn endpoint hoàn toàn có thể trả về các kiểu dữ liệu khác nhau, thì bạn cũng có thể sử dụng ở trong tính Content-Type của request header để xác minh kiểu dữ liệu trả về.

Sử dụng query params nhằm lọc kết quả

Giả sử mình có một endpoint /users để đưa ra danh sách tổng thể users. Nhưng thực tiễn mình chỉ muốn kéo ra các users sinh sống Việt Nam. Một số bạn sẽ nghĩ đến phương pháp tạo một endpoint như hình trạng như /users/vn để xử lý yêu ước này. Tuy vậy bạn không cần phải làm thế, chúng ta có thể coi Việt Nam như một tiêu chí để lọc, cùng endpoint yêu cầu đượ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 để phân trang hoặc sắp đến xếp kết quả thay bởi việc xây đắp 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 # ko tốthttp://api.example.com/users/orderBy?latest # ko tốtSử dụng HTTP method để diễn tả CRUD

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

# Liệt kê list usersHTTP GET http://api.example.com/users # NênHTTP GET http://api.example.com/users/all # không nên# thêm 1 users mới vào danh sáchHTTP POST http://api.example.com/users # NênHTTP POST http://api.example.com/users/create # ko nênHTTP POST http://api.example.com/users/store # ko nên# cập nhật thông tin user tất 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 # không nên# Xóa user bao gồm 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 đề nghị 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 thực hiện được 100% chuẩn của RESTful, bởi

Đa phần những developer chỉ thích sử dụng method POST với GET cho đơn 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 chỉnh 100% RESTful không? Câu vấn đáp là không, chuẩn chỉnh của RESTful là một trong chuyện dẫu vậy nó cũng phải phù hợp với sự thống tuyệt 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 bản thân là càng chuẩn RESTful thì sẽ 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 – giao diện lập trình ứng dụng. đồ họa ở đây không phải là đồ họa của phần mềm, chưa phải là phần nhiều khối màu, bố cục tổng quan của ứng dụng mà mắt các bạn nhìn thấy đâu nhé. Bối cảnh ở đây y như một chuẩn chỉnh chung để kết nối vậy. Ví như cái ổ cắm với dòng phích cắm, tuy vậy chúng hoàn toàn có thể đến từ bỏ hai nhà sản xuất không giống nhau nhưng khi gặm vào nhau thì bọn chúng vẫn vừa khít, đấy là do chúng cùng theo đúng một bối cảnh kết nối.

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

3.2 RESTful API là gì?

RESTful API là rất nhiều API của web service áp dụng theo chuẩn RESTful. Trước khi áp dụng RESTful để tạo API, người ta sẽ đưa ra các chuẩn chỉnh (API) trước. Ví dụ như mình điều khoản nếu tiến hành 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 gồm nội dung là “thành công” chẳng hạn, ai mà lại làm không đúng theo luật lệ này tức là sai API, cùng endpoint đó sẽ chỉ được xem như là RESTful endpoint chứ không hề được coi là RESTful API.

IV. Lời kết

Kết luận lại, nội dung bài viết này mình muốn bạn lưu một số ý bao gồm sau:

RESTful chỉ với một chuẩn chỉnh của web service, ý muốn biết về RESTful thì phải tìm hiểu về web service trước.RESTful không khó, nó chỉ là một trong những tập các quy tắc thôi, tuân theo luật lệ này có nghĩa là bạn đã làm cho được RESTful

Bạn nên làm cái gi tiếp theo?

Nếu chúng ta đã từng thao tác với RESTful rồi, bạn đọc bài viết này chỉ để củng thay thêm kiến thức thì mình hi vọng bạn đang 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 thao tác làm việc với RESTful, hoặc đây là lần đầu tiên bạn nghe thấy có mang này, thì bạn nên làm một thử nghiệm web service nhỏ dại áp dụng RESTful nhằm hiểu hơn nhé, chứ có lý giải hay cố gắng nào thì bài viết này của chính bản thân mình cũng chỉ là triết lý mà thôi.

Xem thêm: Cấu Trúc Và Cách Dùng Have To Nghĩa Là Gì, Cấu Trúc Have To Là Gì

Bài viết được viết dựa trên kinh nghiệm làm việc của bản thân mình và tham khảo một số nguồn. Xin nhận gần như gạch đá.

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

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