2012-04-17 28 views
8

Chúng tôi sẽ triển khai một bộ dịch vụ web REST trong PHP. Chúng tôi đã chọn 2 khung công tác để làm điều đó: Symfony 2 và Silex (vi-khung làm tệp nén phar, dựa trên Symfony2).Dịch vụ web REST: Symfony 2 vs silex

Hiện tại, sẽ chỉ có một vài dịch vụ, với một vài tài nguyên được trả về là GET, nhưng tập hợp phương pháp cuối cùng sẽ phát triển và bao gồm các hành động còn lại khác (đặt/đăng/xóa).

đây là danh sách các ưu và nhược điểm Tôi đã có cho đến nay cho các khuôn khổ 2

Symfony2

Ưu điểm:

  • mạnh hơn
  • thuyết ORM
  • có thể gỡ lỗi với XDebug
  • config trong YML
  • được sử dụng nhiều hơn trong cộng đồng
  • hỗ trợ nhiều hơn
  • autocompletion trong IDE
  • nhanh

khuyết điểm:

  • Cần FOSBundle làm REST (?) (thực ra, tôi muốn biết nếu điều này thực sự hữu ích)

silex

Ưu điểm:

  • nhẹ
  • dường như dễ dàng hơn để tạo ra các url REST của
  • dễ dàng hơn để triển khai (Phar lưu trữ)

Nhược điểm (?):

  • không thuyết ORM
  • không thể debug (Phar lưu trữ)
  • không autocompletion trong IDE
  • cấu hình phải được hardcoded
  • có thể chậm hơn một chút, vì nó là trong một kho lưu trữ Phar?

Bạn nghĩ điều gì là tốt nhất?

Cảm ơn

Trả lời

12

Cá nhân tôi thực sự thích symfony 2, nó dễ dàng để tạo ra các url REST của sử dụng cú pháp chú thích, trong điều khiển của bạn, bạn đặt một cái gì đó giống như

/** 
* @Route("/user/{id}", requirements={"id" = "\d+"}, defaults={"_format"="json"}) 
* @Method({"GET"}) 
*/ 
public function getUser($id) { 
    ... 
} 
/** 
* @Route("/user", defaults={"_format"="json"}) 
* @Method({"PUT"}) 
*/ 
public function putUser() { 
    ... 
} 
+1

Chúng tôi đã quyết định chọn tùy chọn Symfony là – David

+3

Còn https://github.com/FriendsOfSymfony/FOSRestBundle thì sao? – umpirsky

16

Phụ thuộc vào kích thước của dự án của bạn thực sự và kể từ khi bạn nói rằng nó khá nhỏ, tôi đã chọn Silex.

Hầu như tất cả các khuyết điểm bạn liệt kê cho Silex đều bị loại trừ khi bạn include silex through composer. Sau đó, nó chỉ tải phụ thuộc Silex bên trong các nhà cung cấp và bạn không có phí của phar cũng như thiếu hoàn thành mã trong IDE của bạn. Trên thực tế, the PHAR distribution is deprecated.

Đối với Doctrine, Silex có built in Doctrine ServiceProvider liên tục tải Doctrine DBAL trong dự án Silex của bạn. Bạn có thể dễ dàng thêm DoctrineORM hoặc sử dụng một trong số 3rd party serviceProviders được tìm thấy trên github.

Tôi đang xây dựng một REST API khá lớn với Silex và không hối tiếc một điều duy nhất bắt đầu với Silex. Bạn sẽ nhận được rất nhiều lợi thế của các thành phần Symfony2 vì silex được xây dựng với chúng và có một microframework còn lại rất nhẹ mà không cần phải trải qua hàng giờ cấu hình và thiết lập yaml. Thành thật mà nói, tôi phải thừa nhận tôi không phải là một fan hâm mộ lớn của các chú thích, chú thích là tốt nhưng tôi nghĩ rằng các ví dụ được @mcfedr mang nó một chút quá xa nhưng đó chỉ là sở thích cá nhân.

Tôi hy vọng tôi đã debunked một số định kiến ​​bạn có về Silex. Cho nó một swing, bạn sẽ không hối tiếc. Mặt khác, bạn có thể sẽ không hối tiếc Symfony2 hoặc là :)

+1

Xin chào ChrisR. Tôi đã tò mò làm thế nào bạn đang tạo ra bạn tài liệu REST api với dự án Silex của bạn. Bạn làm điều đó bằng tay hoặc bạn đã tìm thấy một loại máy phát điện, như NelmioApiDocBundle cho symfony2. Cá nhân tôi thích Silex, nhưng tôi thực sự xem xét Symfony2 chỉ cho thế hệ tài liệu tự động api. –

+0

Tôi không tự tạo API tài liệu API, đó là danh sách cần làm của tôi :) – ChrisR

+0

@ChrisR Tôi có thể hỏi bạn đã tham gia dự án này như thế nào không? Bạn đã sử dụng chỉ DBAL hoặc thực thể, vv trong API của bạn? – coder4show

Các vấn đề liên quan