2017-01-05 4 views
0

Ich entwerfe einen erholsamen Webservice, um Berichte zu erstellen und zu lesen, die aus einer App erstellt wurden. Beim Erstellen eines Berichts ist es möglich, einige datenschutzrelevante Informationen hinzuzufügen, wie einen Namen, eine Telefonnummer, eine E-Mail usw. Nach dem Erstellen des Berichts wird dieser über denselben Web-Service öffentlich sichtbar gemacht.Restful Web Service, teilweise Leseerlaubnis

POST /report 
{ 
"name":"test", 
"email":"[email protected]", 
"report_contents":.... 
} 

liefert 200 OK mit:

{ 
"id":1, 
"report_contents":.... 
} 

und ein Verfahren sagte zu erhalten Bericht: GET/Bericht/{REPORT_ID}

Ich habe eine andere App, mit der ein Administrator die verwalten Berichte, die über den vorherigen Webdienst erstellt wurden. In dieser Anwendung möchte ich die datenschutzrelevanten Informationen anzeigen. Es verwendet die folgende URL, um einen bestimmten Bericht abzurufen.

GET /report/{report_id} 

die 200 OK zurück:

{ 
"id":1, 
"name":"test", 
"email":"[email protected]", 
"report_contents":.... 
} 

Jetzt gibt es das Problem. Dies ist die exakt gleiche URL. Ist es möglich/konventionell oder sogar eine gute Idee, den gleichen Web-Service für beide Anrufe zu nutzen, aber eine Art von CRUD-Management damit, wo je nach der Rolle des Benutzers ein Teil der Informationen nicht angezeigt/blockiert wird? Oder wäre es besser, einen separaten Webdienst mit Einschränkungen einzurichten?

Antwort

1

Ja, es für verschiedene Darstellungen der gleichen Ressource OK ist auf der gleichen URL für unterschiedliche Anforderungen zurückgegeben werden. So funktioniert Content-Negotiation.

Wenn Sie darüber besorgt sind, kann ich von zwei Möglichkeiten denken:

Eine Möglichkeit ist, einen Abfrageparameter umfassen die Auswahl der Ansichten explizit zu machen und den Zugang kann für jede angesteuert werden. Z.B.

  • /report/{report_id}?view=full
  • /report/{report_id}?view=restricted

Oder Sie könnten auch zwei Unterressourcen betrachten, nannte man /report/{report_id}/full und ein /report/{report_id}/restricted genannt, und dann können Sie einen 40x-Code zurück, wenn der Benutzer nicht richtige Erlaubnis, mit einem Location Header als Hinweis darauf, wo sie aussehen können.

+0

Was Sie sagen, macht viel Sinn. Was ich vergessen habe zu erwähnen, ist, dass ich die API mit einem API-Schlüssel oder Oauth2 schützen werde. Basierend auf der Rolle werde ich zurückgeben, was sie sehen dürfen. – Terabyte

+0

Ist Mehrdeutigkeit kein Problem bei der Definition eines Modells, das zurückgegeben werden soll? – Terabyte

+0

Mehrdeutigkeit wo?Ein REST-Client muss mit dem Empfang verschiedener Repräsentationen umgehen können. – Joe

1

Wenn Ihre Sprache Ihrer Wahl dies unterstützt, könnten Sie ein dynamisches Objekt zurückgeben.

hier ist ein Pseudo-Code.

if (loggedInUser != isAdmin(user)) 
    return new { id: 1, contents: "..." } 
else 
    return new { id: 1, name: "test", email: "[email protected]", contents: "..." } 

Persönlich hätte ich verschiedene Bereiche, die verschiedene Dinge tun. Ein Bereich, der das Modell für alle abruft. In der anderen wäre es wie ein Admin-Bereich.

In dem einen Bereich, haben Sie

Verwandte Themen