Dấu gạch nối, dấu gạch dưới hoặc camelCase làm dấu phân cách từ trong URI?

Tôi đang thiết kế API dựa trên HTTP cho ứng dụng mạng nội bộ. Tôi nhận ra đó là một mối quan tâm khá nhỏ trong sơ đồ lớn của mọi thứ, nhưng: tôi có nên sử dụng dấu gạch nối, dấu gạch dưới hoặc camelCase để phân định các từ trong URI không?

Đây là những suy nghĩ ban đầu của tôi:

lạc đà

• vấn đề có thể xảy ra nếu máy chủ không phân biệt chữ hoa chữ thường
• dường như được sử dụng khá rộng rãi trong các khóa chuỗi truy vấn ( http://api.example.com ? searchQuery = ...), nhưng không phải trong các phần URI khác

Dấu gạch nối

• thẩm mỹ hơn so với các lựa chọn thay thế khác
• dường như được sử dụng rộng rãi trong phần đường dẫn của URI
• không bao giờ thấy khóa chuỗi truy vấn gạch nối trong tự nhiên
• có thể tốt hơn cho SEO (điều này có thể là một huyền thoại)

Gạch dưới

• có khả năng dễ dàng hơn để xử lý các ngôn ngữ lập trình
• một số API phổ biến (Facebook, Netflix, StackExchange, v.v.) đang sử dụng dấu gạch dưới trong tất cả các phần của URI.

Tôi đang nghiêng về phía dưới cho tất cả mọi thứ. Thực tế là hầu hết những người chơi lớn đang sử dụng chúng đều hấp dẫn (xem https://stackoverflow.com/a/608458/360570 ).

Bạn nên sử dụng dấu gạch nối trong URL ứng dụng web có thể thu thập thông tin. Tại sao? Bởi vì dấu gạch nối phân tách các từ (để công cụ tìm kiếm có thể lập chỉ mục các từ riêng lẻ) và không phải là một ký tự từ . Gạch dưới là một ký tự từ, có nghĩa là nó nên được coi là một phần của từ.

Nhấp đúp vào mục này trong Chrome: camelCase
Nhấp đúp vào mục này trong Chrome: under_score
Nhấp đúp vào mục này trong Chrome: gạch nối

Xem cách Chrome (tôi nghe thấy Google cũng tạo ra một công cụ tìm kiếm) chỉ nghĩ một trong số đó là hai từ?

camelCasevà underscorecũng yêu cầu người dùng sử dụng shiftkhóa, trong khi hyphenatedkhông.

Vì vậy, nếu bạn nên sử dụng dấu gạch nối trong ứng dụng web có thể thu thập dữ liệu, tại sao bạn lại bận tâm làm điều gì đó khác biệt trong ứng dụng mạng nội bộ? Một điều ít cần nhớ.

Cách thực hành tốt nhất tiêu chuẩn cho API REST là có dấu gạch nối , không phải dấu mũ hoặc dấu gạch dưới.

Điều này xuất phát từ "Quy tắc thiết kế API REST" của Mark Masse từ Oreilly.

Ngoài ra, lưu ý rằng chính Stack Overflow sử dụng dấu gạch nối trong URL: .../hyphen-underscore-or-camelcase-as-word-delimiter-in-uris

WordPress cũng vậy: http://inventwithpython.com/blog/2012/03/18/how-much-math-do-i-need-to-ledge-to-program-not-that-much-act

Trong khi tôi khuyên bạn nên có dấu gạch nối, tôi cũng phải chủ trương có một câu trả lời không có trong danh sách của bạn:

Không có gì đâu

• API của công ty tôi có URI như thế /quotationrequests/, /purchaseorders/v.v.
• Mặc dù bạn nói rằng đó là một ứng dụng mạng nội bộ, bạn đã liệt kê SEO là một lợi ích. Google khớp với mẫu / foobar / trong một URL cho truy vấn?q=foo+bar
• Tôi thực sự hy vọng bạn không xem xét việc thực hiện cuộc gọi PHP tới bất kỳ chuỗi tùy ý nào mà người dùng chuyển đến thanh địa chỉ, như @ ServAce85 gợi ý!

Nói chung, nó sẽ không có đủ tác động để lo lắng, đặc biệt vì đây là ứng dụng mạng nội bộ chứ không phải ứng dụng Internet sử dụng chung. Đặc biệt, vì là mạng nội bộ , SEO không phải là vấn đề đáng lo ngại, vì mạng nội bộ của bạn không thể truy cập được vào các công cụ tìm kiếm. (và nếu có, nó không phải là một ứng dụng mạng nội bộ).

Và bất kỳ khung nào đáng giá đều là muối đã có cách mặc định để thực hiện điều này hoặc khá dễ dàng để thay đổi cách xử lý các thành phần URL nhiều từ, vì vậy tôi sẽ không lo lắng về điều đó quá nhiều.

Điều đó nói rằng, đây là cách tôi thấy các tùy chọn khác nhau:

Dấu gạch nối

• Mối nguy hiểm lớn nhất đối với các dấu gạch nối là cùng một ký tự (thông thường) cũng được sử dụng để trừ và phủ định số (ví dụ: trừ hoặc phủ định ).
• Hyphens cảm thấy lúng túng trong các thành phần URL. Chúng dường như chỉ có ý nghĩa ở cuối URL để phân tách các từ trong tiêu đề của một bài viết. Hoặc, ví dụ, tiêu đề của câu hỏi Stack Overflow được thêm vào cuối URL cho mục đích rõ ràng về người dùng và SEO.

Gạch dưới

• Một lần nữa, họ cảm thấy sai trong các thành phần URL. Chúng phá vỡ dòng chảy (và vẻ đẹp / sự đơn giản) của một URL, vì về cơ bản chúng thêm một không gian rõ ràng lớn, nặng nề ở giữa một URL rõ ràng, trôi chảy.
• Họ có xu hướng pha trộn với gạch chân. Nếu bạn mong muốn người dùng của mình sao chép-dán URL của bạn vào MS Word hoặc các chương trình chỉnh sửa văn bản tương tự khác hoặc bất kỳ nơi nào khác có thể chọn URL và tạo kiểu cho nó bằng một gạch chân (như các liên kết truyền thống ), thì bạn có thể muốn tránh gạch dưới như dấu phân cách từ. Đặc biệt khi được in, một URL được gạch chân có dấu gạch dưới có xu hướng trông giống như nó có khoảng trắng trong đó thay vì dấu gạch dưới.

Lạc đà

• Cho đến nay, yêu thích của tôi, vì nó làm cho các URL dường như lưu chuyển tốt hơn và không có bất kỳ lỗi nào mà hai tùy chọn trước đó làm.
• Có thể là một chút khó khăn hơn để đọc cho những người có một thời gian khó phân biệt chữ hoa chữ thường từ-, nhưng điều này không nên được nhiều của một vấn đề trong một URL, vì hầu hết các "chữ" nên thành phần URL và ngăn cách bởi một /anyways . Nếu bạn thấy rằng bạn có một thành phần URL dài hơn 2 "từ", có lẽ bạn nên cố gắng tìm một tên tốt hơn cho khái niệm đó.
• Nó không phải là một vấn đề có thể với trường hợp nhạy cảm, nhưng hầu hết các nền tảng có thể được điều chỉnh cho cả hai trường hợp nhạy cảm hoặc case-insensitive. Bất kỳ vấn đề nào cũng chỉ thực sự là vấn đề đối với 2 trường hợp: a.) Con người gõ URL và b.) Các lập trình viên (vì chúng ta không phải là con người) gõ URL. Typose luôn là một vấn đề, bất kể độ nhạy của trường hợp, vì vậy đây là không khác nhau mà tất cả một trường hợp.

Câu trả lời ngắn:

các từ viết thường có dấu gạch nối làm dấu phân cách

Câu trả lời dài:

Mục đích của một URL là gì?

Nếu chỉ đến một địa chỉ là câu trả lời, thì một URL rút ngắn cũng đang hoạt động tốt. Nếu chúng ta không làm cho nó dễ đọc và bảo trì, nó sẽ không giúp các nhà phát triển và bảo trì như nhau. Họ đại diện cho một thực thể trên máy chủ, vì vậy họ phải được đặt tên một cách logic.

Google khuyên bạn nên sử dụng dấu gạch nối

Xem xét sử dụng dấu câu trong URL của bạn. URL http://www.example.com/green-dress.html hữu ích hơn nhiều đối với chúng tôi so với http://www.example.com/greendress.html . Chúng tôi khuyên bạn nên sử dụng dấu gạch nối (-) thay vì dấu gạch dưới (_) trong URL của mình.

Đến từ một nền tảng lập trình, camelCase là một lựa chọn phổ biến để đặt tên cho các từ chung.

Nhưng RFC 3986 định nghĩa các URL là phân biệt chữ hoa chữ thường cho các phần khác nhau của URL. Vì các URL phân biệt chữ hoa chữ thường, giữ cho khóa thấp (chữ thường) luôn an toàn và được coi là một tiêu chuẩn tốt. Bây giờ có một trường hợp lạc đà ra khỏi cửa sổ.

Nguồn: https://metamug.com/article/rest-api-naming-best-practices.html#word-d Friiter

Đây là điều tốt nhất của cả hai thế giới.

Tôi cũng "thích" nhấn mạnh, bên cạnh tất cả những điểm tích cực của bạn về họ, cũng có một phong cách trường học cũ đối với họ.

Vì vậy, những gì tôi làm là sử dụng dấu gạch dưới và chỉ cần thêm một quy tắc viết lại nhỏ vào tệp .htaccess của Apache của bạn để viết lại tất cả các dấu gạch dưới cho dấu gạch nối.

https://yoast.com/apache-rewrite-dash-underscore/