2012-04-04 9 views
17

Obecnie projektuję interfejs API i miałem mały problem: Jak powinien wyglądać adres URL RESTful API, gdy powinieneś być w stanie zidentyfikować przedmiot za pomocą identyfikatora lub ślimaka?Identyfikuj element za pomocą identyfikatora lub wtyczki w interfejsie API RESTful

mogłem myśleć o trzech opcji:

GET /items/<id> 
GET /items/<slug> 

Wymaga to, że ślimak i ID są rozróżnialne, która niekoniecznie jest podane w niniejszej sprawie. Nie mogę myśleć o czystym rozwiązania tego problemu, chyba że można zrobić coś takiego:

GET /items/id/<id> 
GET /items/slug/<slug> 

to będzie działać dobrze, ale nie jest to jedyne miejsce chcę identyfikacji przedmiotów albo przez ślimak lub ID i wkrótce stanie się bardzo brzydki, gdy chce się zastosować to samo podejście do innych działań. To po prostu nie bardzo rozszerzalny, który prowadzi nas do tego podejścia:

GET /items?id=<id> 
GET /items?slug=<slug> 

To wydaje się być dobrym rozwiązaniem, ale nie wiem, czy to jest to, czego można by się spodziewać, a tym samym może prowadzić do frustrujących błędów spowodowanych do niewłaściwego użycia. Ponadto, nie jest to takie proste - lub powiedzmy czyste - aby zaimplementować routing dla tego. Jednak byłoby łatwo rozszerzalny i wyglądają bardzo podobnie do sposobu uzyskania kilka pozycji:

GET /items?ids=<id:1>,<id:2>,<id:3> 
GET /items?slugs=<slug:1>,<slug:2>,<slug:3> 

Ale to ma też wadę: Co zrobić, jeśli ktoś chce się zidentyfikować niektóre przedmioty, które chcą się pobrać z identyfikatorami, ale inni z ślimakiem? Mieszanie tych identyfikatorów nie byłoby łatwe do osiągnięcia dzięki temu.

Jakie jest najlepsze i najszerzej akceptowane rozwiązanie dla tych problemów? Generalnie, co jest ważne podczas projektowania takiego API?

+5

Pytanie w pytaniu, co to jest ślimak? –

+0

Wikipedia mówi: "krótki tekst przyjazny dla użytkownika i SEO użyty w adresie URL do identyfikacji i opisu zasobu" lub coś podobnego. –

+0

Na podstawie przykładów w tym artykule w Wikipedii iw glosariuszu Wordpress (http://codex.wordpress.org/Glossary#Slug) wygląda na to, że ślimak jest częścią już hierarchicznego adresu URL. Więc w twoim przypadku może rzeczy są dla ids, ale przedmioty// (jako przykład) są dla ślimaka. –

Odpowiedz

9

Spośród trzech preferuję trzecią opcję, nie jest niczym niezwykłym, aby zobaczyć tę składnię; na przykład Części Twitter API umożliwiają tę składnię: https://dev.twitter.com/rest/reference/get/statuses/show/id

Czwarta opcja jest hybrydą podejście, gdzie można wybrać jeden (powiedzmy, identyfikator) jako typowe metody dostępu dla pojedynczych elementów, ale również pozwalają zapytań opartych na ślimak. Np .:

GET /items/<id> 
GET /items?slug=<slug> 
GET /items?id=<id> 

Twój routingu będzie oczywiste mapa/szt/id do/przedmioty? Id =

Extensible do wielu IDS/ślimaki, ale nadal spełnia paradygmat reszty dopasowania URI do bazowego modelu danych.

+0

"Paradygmat REST pasujących identyfikatorów URI do podstawowego modelu danych." martwię się o to. Ale myślę, że pójdę z tym. –

+0

To jest prawie pytanie Coke/Pepsi w tych dniach.:) Powiedziałbym, że powinieneś obsługiwać/items/, aby uzyskać certyfikat RESTful, ale także zezwalać na ciąg zapytania, który będzie oparty na wyszukiwaniu w oparciu o id lub slug w ramach paradygmatu. A ja wolę Colę. – Mike

+0

Jako że będę mieć niektóre parametry zapytania więcej do wyszukiwania elementów, które wszystkie zwracają tablicę, byłoby by sprytnie zwrócić tutaj również tablicę? Można wyszukiwać ślimaki, ale nie można jednoznacznie identyfikować przedmiotów, więc wydaje się logiczne, aby zwrócić tablicę. –