Érdekes cikk a témáról.
Kiemelve a cikkből:
URL: You simply whack the API version into the URL, for example: https://haveibeenpwned.com/api/v2/breachedaccount/foo
Custom request header: You use the same URL as before but add a header such as “api-version: 2”
Accept header: You modify the accept header to specify the version, for example “Accept: application/vnd.haveibeenpwned.v2+json”
Ennek kapcsán filózok valamin. A restes cuccok erőforrásokról szólnak, azaz ha adatokban gondolkodunk, entitásokat címzünk meg, azokon végzünk műveletet. De mi van, ha nem egy konkrét entitáson kell végezni műveletet? Pl. Tiltsd le xy usert a rendszerben. Ez sokkal inkább operation jellegű dolog, sok entitást érinthet, az ilyeneket nem szokás rest alapon megcsinálni, jól érzem? De ha nem, akkor hogy?
Could you hire me? Contact me if you like what I’ve done in this article and think I can create value for your company with my skills.
LEAVE A COMMENT
4 COMMENTS
Ilyesmiről volt itt épp beszélgetés:
http://stackoverflow.com/questions/6850187/non-crud-operations-in-a-restful-service
Én kétféle megoldást láttam erre eddig:
– REST api-n át, http PATCH methódussal módosítja az ember az entitásban az adott flag-et
– RPC api-n át publikál tiltás/engedélyezés hívásokat
speter: köszi a linket, az alapján pl., POST /user/disable?
Yvan: ezek szerint lehete pl. PATCH /user/isenabled false payloaddal?
RPC módon nyilván lenne egy DisableUser(userId) metódus, ez egyszerűbb.
Szerintem a peldad pont h REST-specifikus, bar teny, h nem klasszikus CRUD operation (bar akar az is lehetne, az update operationben ugyanis elvben nem kell az osszes attributumnak szerepelni, es egy user enabled tulajdonsagat altalaban pont h a useren taroljuk…). Egyebkent pedig h kod oldalon hany es milyen entitas erintett az a REST szempontjabol erosen irrelevans, az api oldalarol ez egy darab user entitason vegzett modositas. Persze szigoruan szvsz.