REST endpoint aliases, goede praktijk?

[Rekcor]

In ons systeem heb je meerdere soorten accounts:
- menselijke gebruikers
- machines
- apps

In de REST API heb je de volgende endpoints

PHP:

//geeft alle accounts
accounts/ 

//geeft alle menselijke accounts
accounts/mensen/

//geeft het account van mens met accountId  = 1
accounts/mensen/1

//geeft account van machines met accountId  = 2
accounts/machines/2 

//geeft account van apps met accountId  = 3
accounts/apps/3

Wat vinden jullie hiervan? Want je krijgt ook de volgende situaties/vragen:

PHP:

//deze geeft een 400, want account 2 is een machine
accounts/mensen/2

//deze werken ook, maar zijn dus een soort aliases; je weet alleen niet wat voor soort account je terugkrijgt
accounts/1
accounts/2
accounts/3

//wat is hier de beste? ik wil het wachtwoord wijzigen
accounts/mensen/1/wachtwoord
accounts/1/wachtwoord

accounts/machines/2/wachtwoord
accounts/2/wachtwoord

En is het dus goede praktijk om aliases te hebben voor REST - endpoints?

[ Voor 6% gewijzigd door Rekcor op 16-05-2014 12:37 . Reden: wachtwoord weten onzinnig ]

[InZane]

In het 2e voorbeeld heb je het over een wachtwoord opvragen. Wil dit zeggen dat je wachtwoorden als 'plain text' hebt opgeslagen?

[Rekcor]

Goed puntje, nee, maar het ging me even om het voorbeeld. Lees voor 'wachtwoord' 'naam'

[Barryvdh]

Moet het in het EngelsNederlands?

[ Voor 24% gewijzigd door Barryvdh op 16-05-2014 12:48 ]

[Rekcor]

Nee, het is voor een chinese klant, dus eigenlijk staat er: 帐户/2/密码

[Hydra]

Dit gaat in tegen het principe dat er en 1:1 relatie url:resource is. Als je wilt filteren in een lijst met resources zou ik dat gewoon via query params doen.

[Cilph]

De norm is een 1:1 relatie tussen Model en REST Resource.

Ophalen: GET /{modelName}/{id} : Model[JSON | XML]
Alles: GET /{modelName}/ : Array[Model][JSON | XML]
Updaten: PUT /{modelName}/{id} : Model[JSON | XML]
Creëren: POST /{modelName} : Model[JSON | XML]
Delete: DELETE /{modelName}/{id} : Nothing

Zoeken zou ik doen met Query Params op de GET.

[ Voor 8% gewijzigd door Cilph op 16-05-2014 13:50 ]

[Rekcor]

@Cilph, maar wat als een Model een child is van een ander Model (dus: een user is een account, met nog wat extra info)

[Cilph]

Rekcor schreef op vrijdag 16 mei 2014 @ 13:51:
@Cilph, maar wat als een Model een child is van een ander Model (dus: een user is een account, met nog wat extra info)

Als het velden toevoegt, liefst een andere interface. /MachineAccount vs /HumanAccount vs /Account.

Wanneer het een specialisatie is, e.g. een veld type = "Human", gebruik dan gewoon query params.

/Account/?Type=Human : Array[Account]

[ Voor 5% gewijzigd door Cilph op 16-05-2014 13:56 ]

[Rekcor]

Cilph schreef op vrijdag 16 mei 2014 @ 13:54:
[...]


Als het velden toevoegt, liefst een andere interface. /MachineAccount vs /HumanAccount vs /Account.

Kun je ook aangeven waarom?

[Cilph]

Omdat het een directe vertaling is van type safety in object oriented programming.

EDIT: Modulariteit is een ander argument. Je gaat uitbreidingen op Account verweven met de resource van Account zelf, terwijl je dat er juist los van wil.

[ Voor 50% gewijzigd door Cilph op 16-05-2014 14:01 ]

[Rekcor]

Ok, zit wat in ja. Dank!

Zie ook http://stackoverflow.com/...s-where-to-put-parameters

[ Voor 68% gewijzigd door Rekcor op 16-05-2014 14:46 ]