Endpoint là gì

Có yêu cầu bạn là 1 trong developer mới, bạn thấy những developer lành nghề không giống nói với nhau về restful. Quý Khách lần khần restful là gì nên chúng ta lên google tìm kiếm “restful là gì?”. Quý khách hàng hiểu khá nhiều nội dung bài viết rồi tuy nhiên vẫn còn đấy mông lung không biết phương diện mũi thằng restful nạm nào? Nếu nhỏng ai đang Cảm Xúc như thế, thì hãy tham khảo nội dung bài viết này của chính mình nhé.

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

Bài viết này bản thân đã trình bày phần đông vẫn đề bao phủ restful api trước lúc mình trình diễn cụ thể về nó, vậy cho nên bạn hãy kiên trì gọi nhé.


Mục lục


I. Web service là gì?II. Tìm đọc về RESTfulIII. API là gì và RESTful API là gì?

I. Web service là gì?

Website thì ai ai cũng cũng biết rồi, như blog sydneyowenson.com này đó là một trang web kia. Thế nhưng lại web service thì khác, không phải ai ai cũng có cơ hội được nghe thấy các tự này kể từ khi mà Restful trsinh hoạt cần thông dụng.

Web service cũng là một trong ứng dụng web chuyển động tương tự như nhỏng một website, có nghĩa là nhằm truy vấn vào website service chúng ta có thể mlàm việc trình coi sóc lên, gõ vào tkhô giòn cửa hàng url của website service đó. Tuy nhiên không giống với trang web – website để cho người hiểu, thì website service ra đời khiến cho các cỗ máy, hoặc các ứng dụng khác phát âm.

1.1. Tại sao website service ra đời?

Câu cthị trấn kể rằng gồm 2 thằng bạn thương hiệu Quang cùng thương hiệu Bình chơi thân với nhau trường đoản cú hồi nhỏ. Lớn lên, Quang mtại 1 công ty giới thiệu việc tạo cho nhân sự IT, Bình thì mở một công ty giảng dạy nhân sự IT. Một hôm, Quang nói với Bình “mày ơi, cửa hàng tao bao gồm mấy job PHPhường lương cao lắm, ngươi đặt quảng cáo cho tao trong mấy khóa đào tạo và huấn luyện về PHP của dòng sản phẩm nhé“, Bình nghe vậy ngay tắp lự gật đầu luôn luôn, vì xuất sắc cho tất cả hai nhưng. Nhưng sự việc là website tuyển chọn dụng của Quang với website đào tạo và huấn luyện của Bình chạy sống bên trên 2 con VPS không giống nhau, không có một “cây cầu” nào kết nối thân hai trang web này cả.

Quang suy nghĩ mang đến biện pháp vẫn chèn “cứng” quảng cáo của bản thân trong số khóa đào tạo của Bình, nhưng mà Bình gạt đi. Vì chèn cứng những điều đó, lỡ job PHPhường của Quang hết hạn sử dung tuyển chọn dụng thì sao, lại gỡ xuống à? Mà một job thì không vấn đề gì, chứ 100 job thì chỉ bao gồm cyếu lên cùng với gỡ xuống cũng không còn ngày. Bình bèn suy nghĩ ra giải pháp này với bảo Quang, “bên website tuyển chọn dụng của mày, mày khiến cho tao một trang riêng biệt chỉ hiển thị những job PHP nhưng mà mày mong muốn lăng xê, bên trang web của tao sẽ hiểu câu chữ trang web này rồi hiển thị lên“.

Vậy là Quang tạo thành một website riêng rẽ mang lại Bình ở khu vực http://webtuyendungit.com/job-php, Lúc truy vấn vào đó sẽ chỉ nhận thấy câu chữ cạnh tranh hiểu như sau

"jobs": < "url": "http://webtuyendungit.com/tuyen-lap-trinh-vien-php-luong-1000-dollar", "title": "Tuyển dụng xây dựng viên PHPhường. lương 1000 dollar" , "url": "http://webtuyendungit.com/tuyen-lap-trinh-vien-php-khong-kinh-nghiem", "title": "Tuyển dụng lập trình sẵn viên PHPhường ko khiếp nghiệm" , >Sau kia, Bình áp dụng CURL để mang ngôn từ bên trên trang web của Quang, so với thành tài liệu với hiển thị ngon lành lên website huấn luyện và giảng dạy của mình. Giờ trên đây Quang muốn chuyển đổi văn bản quảng bá thì chỉ việc đổi khác văn bản của website trên, cực kỳ thuận lợi cùng dữ thế chủ động.

Trên chính là một ví dụ điển của web service. lúc các ứng dụng không liên quan tới nhau, nhưng mà vẫn ý muốn Bàn bạc dữ liệu cùng nhau thì người ta sẽ suy nghĩ ngay tới bài toán sử dụng website service. Một web service vẫn trả về dữ liệu theo một cấu tạo như thế nào đó (XML hoặc JSON,…) để những áp dụng khác hoàn toàn có thể đọc, đối chiếu và sử dụng được. Như 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ỏng là một điều rõ ràng, bởi vì ngày dần có rất nhiều hệ thống chạy đa gốc rễ nlỗi Facebook, Youtube,.. Thành lập và hoạt động. điểm sáng của những hệ thống chạy nhiều căn nguyên này là luôn luôn tận hưởng năng lực đồng điệu dữ liệu. ví dụ như chúng ta like một status facebook bên trên web, thì trên app cũng buộc phải được diễn đạt, các bạn đăng một bức ảnh lên facebook từ bỏ điện thoại, thì trên website cũng cần bắt gặp. Để có tác dụng được vấn đề đó, tín đồ ta sẽ tạo nên ra một con website service, để khi bạn đăng ảnh, lượt thích giỏi tiến hành bất kỳ hành vi gì các bắt buộc hotline cho tới website service này cho dù hành vi đó được tiến hành tự website tuyệt di động. Mặt không giống, ứng dụng website cùng điện thoại vẫn liên kết vào chung web service để phát âm tài liệu, vì vậy sẽ đảm bảo an toàn được tài liệu là giống như nhau mặc dầu bên trên những gốc rễ khác nhau.

Tóm lại web service Thành lập và hoạt động nhằm mục đích giải quyết và xử lý một vụ việc sau

Giúp những khối hệ thống không tương quan tới nhau vẫn hoàn toàn có thể tiếp xúc được với nhauĐồng bộ tài liệu giữa những nền tảng
*
Web service nằm giữa
1.2 Endpoint của website service

Mỗi URL kèm HTTPhường. method của web service thì được Hotline là một endpoint, nlỗi ví dụ bên trên thì bản thân có http://webtuyendungit.com/job-phpchính là một endpoint. Lúc làm cho một endpoint mang đến web service, bạn sẽ bắt buộc quyên tâm cho tới một vài sự việc sau:

Endpoint áp dụng cấu tạo tài liệu nào nhằm trả về?

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

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

Ví dụ mình có 1 endpoint trả về lên tiếng chi tiết của một user dựa vào ID của user được gửi lên, thì bản thân rất có thể lựa lựa chọn 1 vào nhị giải pháp viết sau (đưa sử ID của user là 1).

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

Hoặc bạn cũng có thể sử dụng một cách viết không giống cũng khá được, nói chung là endpoint được viết thế nào là do các bạn, không có nguyên tắc tầm thường làm sao đến giải pháp viết endpoint cả.

URL sử dụng HTTPhường. Method nào?

Giả sử mình chọn URL bao gồm dạng là http://webservice.com/users?id=1, gắng HTTPhường method là gì được nhỉ? GET tuyệt POST? Câu vấn đáp cũng chính là tùy chúng ta, GET tốt POST cũng rất được, không tồn tại nguyên tắc làm sao cả.

An toàn dữ liệu

Web service Bàn bạc 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 tài liệu trả về trong những endpoint đó cũng bị lộ. Thực tế vẫn có tương đối nhiều vụ lộ đọc tin người tiêu dùng nhưng nguim nhân là vì các endpoint kém bảo mật.

1.3 Các một số loại web service

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

SOAP website service

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

RESTful web service

REpresentational State Transfer, là một trong chuẩn chỉnh của web service. RESTful hoàn toàn có thể áp dụng JSON, XML, plain text, html,.. có tác dụng cấu tạo dữ liệu trả về, gồm quy ước cụ thể về phong thái viết url với http method. Nhưng RESTful không cung cấp chế độ bảo đảm an toàn ban bố trong số endpoint nlỗi SOAPhường. Tuy nhiên bạn cũng có thể sử dụng Json Web Token kết phù hợp với RESTful để giải quyết và xử lý sự việc này, nên việc không có sẵn lý lẽ an ninh ban bố không hẳn là vấn đề xứng đáng sợ hãi khi áp dụng RESTful.

SOAPhường vs RESTful

Ngày ni những dự án web service phần nhiều (thậm chí gần như là tất cả) phần lớn áp dụng RESTful cầm cố do thực hiện SOAP. Bởi nhỏng mình nhắc ra ở trên thì chúng ta thấy RESTful gồm quy ước rõ ràng hơn nhiều SOAP.. Mặt không giống RESTful hoàn toàn có thể sử dụng nhiều nhiều loại tài liệu nhằm trả về, trong số ấy gồm cả XML, vậy xét sống góc nhìn làm sao kia có thể nói rằng rằng RESTful bao gồm cả SOAPhường cũng ko không nên.

Tuy nhiên SOAP vẫn còn được thực hiện trong vô số nhiều dự án công trình cũ rất cần được gia hạn, yêu cầu chúng ta mà lại tò mò được SOAP nữa thì càng giỏi.

II. Tìm đọc về RESTful

Bài viết viết về RESTful mà lại quá ttránh về web service. Mình trình diễn điều đó là do theo như đúng trình từ bỏ thì loại bọn họ biết trước phải là website service, tiếp đến new là RESTful. Nhưng do RESTful đang là 1 trong những từ bỏ khóa hot, đề xuất chúng ta có xu hướng mày mò về RESTful trước mà xem nhẹ mất dòng nơi bắt đầu web service.

Xem thêm: I Ệt 'I - Nhân Viên Ie Là Gì

Sau đây mới thật sự là những gì bạn có nhu cầu tìm hiểu về RESTful nhé.

RESTful có khối hệ thống phép tắc chặt chẽ về các viết endpoint với HTTPhường method, bản thân đang nắm tắt một vài hình thức đặc biệt quan trọng tạo ra sự “thương hiệu tuổi” của RESTful để các bạn luôn tiện theo dõi và quan sát.

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

Nếu là web developer, chắc hẳn rằng bạn nghe biết method GET cùng POST. Nhưng với RESTful thì gồm thêm một vài method mới, kèm cách áp dụng tương ứng nhỏng sau:

GET: được sử dụng để mang ban bố trường đoản cú máy chủ theo URI vẫn cung ứng.POST: gửi lên tiếng tới máy chủ thông qua những biểu mẫu mã http (đăng kí chẳng hạn..)HEAD: giống với GET dẫu vậy response trả về không tồn tại body toàn thân, chỉ tất cả headerPUT: ghi đè toàn bộ ban bố của đối tượng người sử dụng cùng với đều gì được gửi lênPATCH: ghi đè các thông tin được đổi khác của đối tượng người tiêu dùng.DELETE: xóa tài nguyên bên trên hệ thống.CONNECT: tùy chỉnh một liên kết tới VPS theo URI.OPTIONS: biểu hiện các tùy lựa chọn giao tiếp mang đến resource.TRACE: triển khai một bài test loop – baông xã theo đường truyền mang lại resource.

Thực tế thì mình new chỉ thao tác cùng 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ờ, tuy nhiên sau này chắc chắn là vẫn gặp gỡ :p.

2.2 Quy ước về resource, endpoint

Resource Có nghĩa là tài nguim, mà lại đây là một có mang được nói tới những trong RESTful, cần bản thân đang giữ nguyên từ khoá này nhưng mà không Việt hóa nhé.

Resource đó là tài liệu nhưng mà họ yêu cầu làm chủ, hoàn toàn có thể là customers, products, posts, images, videos… Mặt khác, tên resource cũng trở nên xuất hiện thêm trong cách viết endpoint, phải nếu khách hàng viết tên đến resource một giải pháp công nghệ, thì endpoint cũng bị dễ dàng nắm bắt cùng dễ tiếp xúc hơn.

Xem ví dụ vào bảng sau nhằm nắm rõ đâu là resource, cùng resource thường được viết thế nào trong những 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 phép tắc nhằm bạn xem thêm về kiểu cách đặt tên resource sao cho tuyệt.

Sử dụng danh từ bỏ để đặt thương hiệu mang đến resource

RESTful tổ chức triển khai resource dưới dạng các đối tượng người tiêu dùng, vày vậy resource đề nghị được đặt tên bên dưới dạng dạng một danh từ bỏ chứ đọng không phải một cồn từ. Giả sử bản thân bao gồm một trong những resource là: users, posts, thì resource tương ứng sẽ tiến hành viết trong các endpoint nlỗi sau:

http://api.example.com/users # Liệt kê tất cả userhttp://api.example.com/users/1 # Chi huyết user có ID là 1http://api.example.com/posts # Liệt kê toàn bộ posthttp://api.example.com/posts/1 # Chi ngày tiết post có ID là 1Sử dụng đấu sượt (/) nhằm diễn tả mối quan hệ phân cung cấp thân các resources

Trong thực tiễn, những resource thông thường sẽ có quan hệ cùng nhau. lấy ví dụ mình gồm resource user, từng user lại có nhiều resource image. Thì minh có thể xây cất những endpoint nlỗi sau

http://api.example.com/users # Liệt kê toàn bộ usershttp://api.example.com/users/1 # Chi máu 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 ốp ngang (-) nhằm phân làn giữa các các từ

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

Vậy tại vì sao (1) lại giỏi rộng (2)? Nguyên nhân là dâu gạch men bên dưới (_) bị dựa vào nhiều vào font chữ hiển thị, trong một trong những trường thích hợp nó rất có thể bị che mất một phần, hoặc bị xóa, hoặc bị gửi thành vết cách trên một số trong những trình chuyên chú. Vấn đề này thuận tiện tạo ra nhầm lẫn cho những người sử dụng.

Sử dụng chữ hay cho toàn bộ endpoint

http://api.example.com/banned-users # Tốt (1)HTTP://API.WEBSERVICE.COM/banned-users # Không xuất sắc (2)http://api.example.com/BANNED-USERS # Không xuất sắc (3)Trong mỗi endpoint, ngoại trừ phần giao thức và phần domain, thì các phần sót lại sẽ phân minh chữ hoa chữ thường. Tức là ta có endpoint (1) sẽ tương tự với endpoint (2), nhưng mà endpoint (3) thì khác trọn vẹn.

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

Không thực hiện đ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 # ko tốt (2)http://api.example.com/banned-users.xml # ko tốt (3)Đuôi mở rộng chính là .json và .xml vào endpoint (2) cùng (3) sinh sống ví dụ bên trên. Một số chúng ta cũng có thể thấy rằng điều đó là tường minc hơn, rằng Lúc tôi truyền .json tức thị tôi ao ước đem tài liệu dạng json cùng giống như với xml. Tuy nhiên làm điều này không hẳn là cách hay vì:

Endpoint dài thêm hơn cùng nhìn có vẻ xấu xíquý khách hàng vẫn yêu cầu bảo trì những endpoint hơn

Nếu như các bạn vẫn mong endpoint rất có thể trả về không ít phong cách dữ liệu khác biệt, thì bạn cũng có thể sử dụng thuộc tính Content-Type của request header nhằm khẳng định thứ hạng dữ liệu trả về.

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

Giả sử bản thân bao gồm một endpoint /users để mang ra danh sách tổng thể users. Nhưng thực tế tôi chỉ mong mỏi mang ra những users ở toàn nước. Một số bạn sẽ suy nghĩ mang lại cách sinh sản một endpoint nhỏng vẻ bên ngoài nlỗi /users/vn nhằm xử lý từng trải này. Tuy nhiên bạn không nhất thiết phải có tác dụng chũm, bạn cũng có thể coi Việt Nam nhỏng một tiêu chuẩn để lọc, và endpoint đề xuất được viết như thế này

http://api.example.com/users?country=vn # giỏi. Sử dụng query params countryhttp://api.example.com/users/vn # không tốtquý khách cũng cần áp dụng query params để phân trang hoặc thu xếp hiệu quả vắt vì chưng Việc thiết kế 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=lakiểm tra # Tốthttp://api.example.com/users/orderBy/lachạy thử # Không tốthttp://api.example.com/users/orderBy?latest # Không tốtSử dụng HTTP.. method nhằm bộc lộ CRUD

Bạn không nên bộc lộ các làm việc với resource bằng bài toán đã cho thấy trên URI, cụ vào đó bạn hãy sử dụng những HTTP method khớp ứng.

# Liệt kê danh sách usersHTTP GET http://api.example.com/users # NênHTTPhường. GET http://api.example.com/users/all # Không nên# Thêm một users mới vào danh sáchHTTPhường POST http://api.example.com/users # NênHTTPhường POST http://api.example.com/users/create # Không nênHTTP.. POST http://api.example.com/users/store # Không nên# Cập nhật đọc 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ênHTTPhường 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ênHTTPhường 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 Có nhất thiết bắt buộc tuân theo 100% chuẩn RESTful không?Thực tế mình trải qua những dự án công trình thực hiện RESTful thì chưa có dự án như thế nào thực hiện được 100% chuẩn chỉnh của RESTful, bởi

Đa phần những developer chỉ say đắm cần sử dụng method POST và GET đến solo giảnMột số chủ kiến cho rằng /users/1 khó khăn áp dụng rộng /users?id=1

Vậy gồm độc nhất vô nhị thiết là buộc phải chuẩn chỉnh 100% RESTful không? Câu vấn đáp là không, chuẩn của RESTful là 1 trong những cthị trấn cơ mà nó cũng đề nghị cân xứng với sự thống độc nhất vô nhị của team, cân xứng cùng với tính chất của dự án công trình. Nhưng ý kiến của bản thân mình là càng chuẩn RESTful thì càng giỏi.

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

3.1. API là gì?

API là viết tắt của Application Programing Interface – đồ họa thiết kế ứng dụng. Giao diện tại đây chưa phải là bối cảnh của phần mềm, chưa hẳn là rất nhiều khối hận color, bố cục của phần mềm cơ mà đôi mắt chúng ta nhìn thấy đâu nhé. Giao diện ở chỗ này hệt như một chuẩn chỉnh chung nhằm liên kết vậy. lấy ví dụ như nhỏng chiếc ổ gặm với cái phích cắn, mặc dù chúng hoàn toàn có thể tới từ nhị nhà cung cấp khác nhau nhưng lại khi gặm vào nhau thì bọn chúng vẫn vừa vặn, đấy là vày chúng cùng tuân theo một giao diện kết nối.

Vì một trong những phần mềm chứa rất nhiều súc tích tinh vi, đề nghị fan ta tra cứu biện pháp chia nhỏ dại nó ra thành nhiều phần, mỗi phần này tạm thời Call là 1 trong component. Mỗi component sẽ sở hữu tính hòa bình cao, không nhiều phụ thuộc hoặc hoàn toàn có thể ko phục nằm trong vào những thành phần khác. Tuy là có tính tự do cao, nhưng lại nhằm có thể liên kết được cùng nhau cơ mà một trong những phần mượt hoàn chỉnh, buộc bọn chúng vẫn bắt buộc tuân thủ theo đúng một hoặc một trong những chuẩn như thế nào đó. Thì mỗi loại chuẩn đó được Gọi là một hình ảnh thiết kế vận dụng – xuất xắc chính là một API.

3.2 RESTful API là gì?

RESTful API là phần đa API của website service sử dụng theo chuẩn chỉnh RESTful. Trước khi vận dụng RESTful nhằm chế tác API, bạn ta đã giới thiệu các chuẩn (API) trước. ví dụ như mình luật pháp nếu triển khai thêm users thành công, thì đã yêu cầu trả về header status là 200, kèm một tin nhắn tất cả văn bản là “thành công” ví dụ điển hình, ai nhưng làm cho không đúng theo quy tắc này Có nghĩa là không đúng API, và endpoint đó sẽ chỉ được xem là RESTful endpoint chứ không hề được xem như 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 thích các bạn lưu một số trong những ý chủ yếu sau:

RESTful chỉ là 1 chuẩn của web service, ý muốn biết về RESTful thì buộc phải tò mò về web service trước.RESTful không cạnh tranh, nó chỉ là 1 trong tập những nguyên tắc thôi, tuân theo luật lệ này Tức là chúng ta vẫn có tác dụng được RESTful

quý khách bắt buộc làm những gì tiếp theo?

Nếu các bạn đã có lần làm việc cùng với RESTful rồi, độc giả nội dung bài viết này chỉ để củng cố thêm kỹ năng và kiến thức thì mình mong muốn bạn vẫn hiểu hơn về nó qua cách giải thích của bản thân. 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 thứ nhất chúng ta nghe thấy quan niệm này, thì bạn nên làm một thử nghiệm website service nhỏ tuổi vận dụng RESTful để đọc rộng nhé, chđọng bao gồm lý giải xuất xắc 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ỉ với lý thuyết mà lại thôi.

Xem thêm: Autodesk Autocad 2010 64Bit ), Auto Cad 2010 (32Bit + 64Bit) Full + Crack Đây!

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

Tài liệu tsay mê khảo: https://restfulapi.net

(*) CURL: là bộ thỏng viện được thực hiện sẽ giúp đỡ triển khai bài toán chuyển tài liệu trải qua các giao thức không giống nhau như HTTPhường, FPT…


Chuyên mục: Công Nghệ