Thiết kế API cho dữ liệu không gian

Tôi đang xem xét việc cố gắng tạo một API để tôi có thể cung cấp một số bộ dữ liệu không gian cho các đồng nghiệp để phân tích.

Một phần công việc của tôi là phân tích và chuẩn bị dữ liệu mà sau đó có thể được sử dụng để phân tích thêm bởi những người khác. Công việc (trong khi hiện tại ở quy mô nhỏ hơn và kém tinh vi hơn) tương tự như đi bộ nhưng liên quan đến một số bộ dữ liệu khổng lồ. Ngày càng có nhiều hạn chế về cách tôi có thể chia sẻ dữ liệu gốc, nhưng tác phẩm phái sinh của tôi có thể chia sẻ được. Tôi đã suy nghĩ về cách tốt nhất để chia sẻ kết quả phân tích của mình (ngoài việc truyền các bộ dữ liệu lớn) và nghĩ rằng API sẽ là một cách tiếp cận. Tôi nên nghĩ về điều gì khi xây dựng API? Có thông số kỹ thuật thiết kế mà tôi có thể làm theo?

Tầm nhìn của tôi nghe có vẻ hoành tráng hơn một chút so với hiện tại, nhưng tôi nghĩ nó sẽ là một khuôn khổ hữu ích để xem xét sớm trong công việc này.

Theo API, tôi cho rằng bạn có nghĩa là một số loại quyền truy cập mạng vào dữ liệu của bạn thông qua một loại HTTP POST / GET, chẳng hạn như API Google Maps? Nó sẽ là dữ liệu raster hoặc vector? Tôi sẽ giả sử vector cho các mục đích của cuộc thảo luận này. Đây thực sự chỉ là một giao thức giao tiếp chứ không phải là Giao diện lập trình ứng dụng.

Bạn sẽ không cần thiết kế bất cứ thứ gì từ đầu, bởi vì có rất nhiều giao thức tiêu chuẩn (thay vì API mỗi lần, tôi có một chút lỗi khi gọi API mọi thứ khi chúng không, nhưng tôi sẽ không chán bạn! ). Nếu bạn chỉ quan tâm đến việc cung cấp dữ liệu vectơ chỉ đọc cho khách hàng của mình, bạn chỉ cần một Máy chủ WFS đặt trước cơ sở dữ liệu của bạn. Tôi đã sử dụng GeoServer trước đây, nhưng tôi thích sự nhẹ nhàng của TinyOWS . Cả hai đều làm cùng một công việc: cấu hình chúng để truy cập cơ sở dữ liệu của bạn về dữ liệu dẫn xuất, đặt chúng chạy như một phần của máy chủ web ( Apache là phổ biến, nhưng tôi thích lighttpd), Và bạn có nó rồi đấy. QGIS có thể tải dữ liệu từ máy chủ WFS và Arc chắc chắn cũng vậy. OpenLayers cũng có khả năng hiển thị WFS cho một giải pháp dựa trên trình duyệt. Ở cấp độ thấp hơn, GDAL có thể được sử dụng để chuyển đổi dữ liệu từ WFS sang bất kỳ định dạng vector nào hỗ trợ OGR.

Nếu bạn muốn khả năng chỉnh sửa, cả GeoServer và TinyOWS đều hỗ trợ WFS-T, cho phép người dùng của bạn tải các phân tích của họ trở lại máy chủ của bạn.

Tạo API của riêng bạn thực sự đánh bại mục đích có các tiêu chuẩn này ngay từ đầu, trừ khi bạn cực kỳ chuyên môn và bạn có các yêu cầu cụ thể như hiệu suất và ... đó là tất cả những gì tôi có thể nghĩ tới. Đi theo con đường này, không có một lượng tài nguyên hợp lý là một nhiệm vụ - mặc dù không phải là không thể -.

Bạn có một cặp đôi tùy chọn; sự lựa chọn sẽ phụ thuộc vào mô hình dữ liệu của bạn, loại dữ liệu sẽ được phục vụ, mô hình sử dụng dự định, kiểm soát truy cập cũng như nền tảng phân phối (Web, HTML, Java Server, IIS, tập dữ liệu tĩnh).

1. Mở rộng một sản phẩm hiện có để sử dụng bộ dữ liệu của bạn. Bạn có thể xem việc lưu trữ một cá thể GeoServer trên máy tính (hoặc dành riêng?) Của bạn và phân phối dữ liệu của bạn theo cách đó. Nếu dữ liệu của bạn không phải là định dạng mà GeoServer có thể hiểu, bạn có tùy chọn viết gói Java để cung cấp khả năng đó. Ưu điểm là bạn có một tiêu chuẩn được xác định rõ ràng để cung cấp thông tin không gian cho cả trực quan hóa (WMS) và thao tác / tải xuống tính năng (WFS), cũng như các lợi ích khác như gắn thẻ địa lý và ốp lát.
2. Chọn tùy chọn API của bạn và bạn có toàn quyền kiểm soát cách người dùng giao diện với nó. Điều này đến với nhiệm vụ đầu tiên của bạn, Xác định cách bạn muốn người dùng tương tác với dữ liệu của bạn. Giao diện này cho dữ liệu của bạn sẽ là chìa khóa giữa thành công hay thất bại. Nếu giao diện của bạn quá mở, nó có thể trở nên phức tạp và không sử dụng được, quá đơn giản và hạn chế, chậm hoặc không chấp nhận. Dù bằng cách nào, việc xác định cách bạn muốn người dùng truy cập dữ liệu của bạn và cách bạn dự đoán người dùng sẽ muốn sử dụng dữ liệu của bạn sẽ rất quan trọng.

Chúc may mắn, một API không phải là một công việc nhỏ vì bạn cần xem xét phương pháp phát hành và chu trình, sửa lỗi, kiểm tra. Tất cả những điều này đóng góp cho khả năng sử dụng. Tôi không nói đừng làm điều đó, nó sẽ là một trải nghiệm tuyệt vời. Mặc dù xây dựng trên một sản phẩm hiện có cũng có thể là một kinh nghiệm tích cực.