Was für Raum in REST-URI?

Was sollte ich verwenden:

  • /findby/name/{first}_{last}
  • /findby/name/{first}-{last}
  • /findby/name/{first};{Letzte}
  • /findby/name/first/{erste}/last/{last}

etc.

URI repräsentiert eine Person-Ressource mit 1 Namen, aber ich muss logisch trennen den ersten vom letzten zum identifizieren jeder. Ich mag die Art von dem letzten Beispiel, weil ich tun kann:

  • /findby/name/first/{first}
  • /findby/name/last/{last}
  • /findby/name/first/{erste}/last/{last}

InformationsquelleAutor Droo | 2010-04-09

  1. 13

    Konnte man immer nur akzeptieren Leerzeichen 🙂 (querystring entkam als "%20")

    Aber meine Präferenz ist, einfach verwenden Sie Bindestriche (-) ... sieht schöner aus in der URL. es sei denn, Sie müssen in der Lage sein, um im wesentlichen die Abfrage, in dem Fall das Letzte Beispiel, das ist besser, als Sie bemerkte

    InformationsquelleAutor Joel Martinez

  2. 12

    Warum nicht + für Raum?

    Ich bin ratlos: Striche, minus, Unterstrich, %20... warum nicht einfach +? Dies ist, wie die Räume sind normalerweise codiert Abfrage-Parameter. Ja, Sie können mit %20 zu, aber warum sieht häßlich aus.

    Ich tun würde, 

    /personNamed/Joe+Blow
    Dies machte meinen code gerne. Danke.

    InformationsquelleAutor Nas Banov

  3. 2

    Ich gerne mit "_", weil es die meisten ähnlichen Charakter zu Raum hält, dass die URL lesbar.

    Jedoch die URLs, die Sie zur Verfügung gestellt scheinen nicht wirklich Erholsam. Eine URL sollte eine Ressource, aber in deinem Fall stellt er eine Suchanfrage. Also ich würde so etwas tun:

    /people/{first}_{last}
/people/{first}_{last}_(2)  - in case there are duplicate names

    Es in diesem Fall speichert man den slug ({first}_{last}, {first}_{last}_(2)) für jede Benutzer-Datensatz. Eine weitere option zum voranstellen-ID, so dass Sie nicht haben, um sich mit Schnecken:

    /people/{id}-{first}_{last}

    Und für die Suche verwenden Sie die non-RESTful URLs:

    /people/search?last={last}&first={first}

    Diese würde die Anzeige einer Liste von Suchergebnissen, während die URLs über die Seite für eine bestimmte person.

    Ich glaube nicht, dass es jeder verwenden, der macht die Suche nach RESTful URLs, die Benutzer werden wahrscheinlich wollen, um links zu teilen, um eine bestimmte person die Seite und nicht den Suchergebnisseiten. Wie für die Suchmaschinen, vermeiden, dass die gleichen Inhalte für mehrere URLs, und Sie sollten sogar zu leugnen, Indizierung Ihrer suchergebnis-Seiten in robots.txt

    Es gibt keine solche Sache wie eine RESTful-URL. Der Inhalt/Struktur einer URL ist undurchsichtig, um einen Erholsamen system. Die Ergebnisse einer Suche ist eine Ressource zu.

    InformationsquelleAutor Leventix

  4. 2

    Für die Suche:

    /people/search?first={first}&last={last}
/people/search?first=george&last=washington

    Für Ressourcen Pfade:

    /people/{id}-{first}-{last}
/people/35-george-washington

    Wenn Sie mit Ruby on Rails v3 in standard-Konfiguration, hier ist, wie Sie es tun können.

    # set up the /people/{param} piece
# config/routes.rb
My::Application.routes.draw do
  resources :people
end

# set up that {param} should be {id}-{first}-{last}
# app/models/person.rb
class Person < ActiveRecord::Base
  def to_param
    "#{id}-#{to_slug(first_name)}-#{to_slug(last_name)}"
  end
end

    Beachten Sie, dass Ihr Vorschlag, /findby/name/first/{first}/last/{last}, ist nicht erholsam. Es nicht benennen von Ressourcen und es nicht benennen Sie diese kurz und bündig.

    Die REST-Einschränkung bedeutet, dass die Letzte URL verletzen?
    Ich bin mir nicht bewusst, dass es eine Checkliste, die definiert, was es bedeutet, im REST.
    Ja, es gibt. Der REST architektonischen Stil, der definiert wurde, indem ein Satz von Einschränkungen, die null-Stil. Hier nordsc.com/ext/classification_of_http_based_apis.html ist eine gute Tabelle für die Ermittlung, ob ein system erholsamen oder nicht.

    InformationsquelleAutor yfeldblum

  5. 0

    Den modernsten Wahl sollte immer und in Erster Linie betrachten wir zwei Constraints:

    1. Wie du wirst nie wissen, wie gut der Entwickler oder das Gerät umgesetzt werden, ist hinsichtlich der Handhabung von urlendoding, ich werde immer versuchen, mich selbst zu begrenzen,die Tabelle der sichere Zeichen, wie man Sie in der ausgezeichneten rant (Bitte keine Unsichere Zeichen in URLs
    2. Auch - wir wollen prüfen, der client verbraucht die API. Können wir die gesamte Struktur problemlos dargestellt werden und zugänglich in die client-seitige Programmiersprache? Was Sonderzeichen würde diese requierement lässt uns mit? I. e. ein $ wird gut in javascript-Variablen-Namen, und somit direkt zugänglich in der analysierten Folge, aber eine PHP-client weiterhin verwenden eine komplexere (und potenziell verwirrende) Schreibweise $userResult->{'$mostVisited'}->someProperty..., dass ein Schuss in den eigenen Fuß! So für die zwei (und ein paar andere Programmier-Umgebungen) unterstreichen scheint die einzige gültige option ist.

    Sonst bin ich meist einig mit @yfeldblum Antwort - ich würde verschiedene zwischen ein Suche-Endpunkt vs. die tatsächliche einzigartige Ressource lookup. Fühlt sich mehr RUHE, um mich, aber noch wichtiger ist, haben die beiden eine erheblichen Kosten Unterschied auf die api-server - auf diese Weise können Sie leichter ausgeprägt, und also verlangen einen höheren Kosten-oder rate-limit-der-Suche-Endpunkt - sollten Sie jemals brauchen es.

    Zu Pragmatisch, im Gegensatz zu einem "RESTafarian" genannten Ansatz /people/35-george-washington könnte (und sollte imho) grundsätzlich reagieren nur die id, also, wenn Sie wollen einen Namen, urlsafe-für-dummies-link, Liste der Referenz-als /people/35_george_washington. Andere Ideen konnten /people/35/#GeorgeWashington (so brechen die Tonnen von RFCs) oder /people/35_GeorgeWashington - die API würde nicht interessieren.

    InformationsquelleAutor Philzen

Schreibe einen Kommentar