Określanie rzutowania dla zapytania REST GET

Question

Czy określanie rzutowania dla zapytania REST GET narusza zasadę REST i/lub czy jest to dobra praktyka?
Rozważmy API jak /person?fields=fname,lname, address, to może być, bo człowiek jest wielkim wzorem i dla mojego obecnego wymogu i wymagają jedynie wartość danego pola (powiedzmy Tworzę siatkę UI)

Answer 1

to całkowicie w porządku, aby zdefiniować nowy zasób, jeśli obecne nie obsługuje tego, co chcesz. Tak właśnie działa usługa REST.

Tak więc w twoim przypadku definicja URI /person?fields=fname,lname, address jest całkowicie poprawna.

Zwróć uwagę, że struktura URI nie ma znaczenia, musisz podać linki do klientów, w których opisujesz szablon URI i zmienne. Należy więc zwrócić łącza coś takiego (fikcyjna Hypermedia formacie JSON):

{ 
    "_links": { 
     "/meta/person/list": { 
      "href": "/person{?fields}", 
      "vars": { 
       "fields": { 
        "required": false, 
        "composition": [ 
         "fname": { 
          "meta": "/meta/person/fname" 
         }, 
         "lname": { 
          "meta": "/meta/person/lname" 
         }, 
         "address": { 
          "meta": "/meta/person/address", 
          "alternatives": { 
           "href": "/locations", 
           "meta": "/meta/locations" 
          } 
         } 
        ] 
       } 
      } 
     } 
    } 
} 

W którym /meta opisuje rodzaje i etykiecie każdego params:

GET/meta/osoba/FName

{ 
    "type": "string", 
    "label": "First name", 
    "_links": { 
     "self": { 
      "href": "/meta/person/fname" 
     } 
    } 
} 

Ofc. Twoim pierwszym krokiem z klientem powinno być uzyskanie całej meta lub przynajmniej najczęściej używanych jej części. Przetwarzając łącze, klient musi być w stanie zrozumieć opis meta i tylko ten specjalny format JSON hipermedii. Struktura URI jest całkowicie nieistotna, powinna używać tylko meta, aby zrozumieć, czym jest link i jak z niego korzystać.

Niestety, obecnie nie posiadamy standardu opisywania linków w odpowiedzi na JSON. Istnieją formaty hipermedialne, takie jak Hydra + Json-LD, HAL, HyperSchema itd. ... Ale afaik. żaden z nich nie jest jeszcze standardem. (Prawdopodobnie najbliżej stanie się wokal Hydra RDF, ale z pewnością nie jest jeszcze gotowy do produkcji, Json-LD już jest standardowym sposobem reprezentowania RDF.)

Teraz, jeśli jest on zakodowany na kliencie, jak budować Identyfikator URI i co to znaczy, to nie jest klientem REST, ponieważ ten rodzaj usług/klientów narusza ograniczenie REST w postaci uniform interface/HATEOAS. Ofc. obecnie ppl. wywołaj wszystko jako REST, RESTful, API, nawet jeśli znają tylko tyle co Jon Snow na ten temat. Btw. nie ma tragedii, jeśli nie chcesz wdrożyć swojej aplikacji internetowej w trybie REST, zależy to tylko od twoich wymagań. Na przykład, jeśli twoja aplikacja nie będzie miała wielu użytkowników i deweloperów zewnętrznych, najprawdopodobniej nie będzie miała znaczenia, którą ścieżkę wybierzesz.