REST-es webservice eseten a POST-ot mire hasznaljatok es mire nem?

Wikipedia igy foglalja ossze:

http://en.wikipedia.org/wiki/Representational_state_transfer#Example

Collection URI, such as: http://example.com/resources/

GET List the URIs and perhaps other details of the collection's members.
PUT Replace the entire collection with another collection.
POST Create a new entry in the collection. The new entry's URI is assigned automatically and is usually returned by the operation.
DELETE Delete the entire collection.

Element URI, such as http://example.com/resources/item17

GET Retrieve a representation of the addressed member of the collection, expressed in an appropriate Internet media type.
PUT Replace the addressed member of the collection, or if it doesn't exist, create it.
POST Not generally used. Treat the addressed member as a collection in its own right and create a new entry in it.
DELETE Delete the addressed member of the collection.

Figyeljuk meg a POST definiciojat: altalaban nem hasznaljuk, ill. amire hasznaljuk: egyedi elem eseten, ha az URI altal megadott egyedi elem onmaga is egy kollekcio, akkor ahhoz ad hozza egy uj elemet.

Tehat egyedi elem eseten a PUT szempontjabol nincs kulonbseg letezo vagy nem letezo elofordulas kozt, lecsereli azt. (Az egyedi elem a PUT altal megadott uj erteket vogja felvenni, lenyegtelen, hogy letezett-e mar korabban vagy nem.)

A POST viszont _mindig_ egy kollekciohoz ad uj erteket. Ezert ha egyedi elemet cimez az URI, akkor a POST nem az elemet csereli, ami most tehat maga is egy kollekcio, hanem az elemet, ami tehat egy kollekcio, boviti egy uj elemmel.

Visszaterve a PUT-ra: mindig cserel (a nem letezot is csereli), soha nem kreal, mig a POST mindig uj erteket ad a meglevok melle, tehat soha nem cserel.

CRUD-ra leforditva:
Create POST
Read GET
Update PUT
Delete DELETE

Ki hogy hasznalja, arra vagyunk kivancsiak.

Elore is koszonet a valaszokert!

Hozzászólások

Igy:

example.com/rest/persons:

get: visszaadja a listát
post: hozzáad egyet

example.com/rest/persons/{personId}

get: visszaadja az elemet
put: modosít
delete: töröl

Kicsit off, de már sok ilyen fórumtémát és cikket láttam, és mindig azon gondolkodok el, hogy van-e értelme ennek a REST-nek egyáltalán, ha programsorok írása helyett a konvenciókon való agyalással megy el a fejlesztők drága ideje. Szerintem a legtöbb rendszer elég hamar eljut egy olyan szintre, ahol az egyszerű GET/POST/stb. szisztéma már nem fed le minden igényt, és ilyenkor kezdünk el mindenfélét belemagyarázni, hogy legyen értelme. Konkrétan egyébként ez egy válasz is a kérdésre, tehát ha már REST, akkor találj ki magadnak konvenciókat, nem fogsz olyat találni, ami mindig mindenkinek minden helyzetben jó lesz.

--

Pont ezért vannak a konvenciók, hogy a projekten belül próbáljuk meg egységesen kezelni a dolgokat. Aztán ha kell, akkor újratervezünk, és gányolás helyett inkább refaktorálunk.

Ami a fő szívásfaktor szokott lenni, az az, amikor nem terveznek meg normálisan egy projektet, nincsenek konvenciók, és mindenki baromira ideges, mert nem tudja, ha valamibe belenyúl, mikor dől össze az egész. Na, ez az, ami drága...

A POST új elemet hoz létre a URI-ben megadott kollekció alatt. Például: POST /articles.

A POST és a PUT közötti legnagyobb különbség, hogy a PUT kérésében használt URI egyértelműen azonosítja a lecserélendő vagy létrehozandó elemet. Például: PUT /articles/1. A POST esetén nem lehet előre tudni, hogy milyen azonosítója lesz az elemnek, míg a PUT esetén igen. Amit írtál az nem igaz ("mindig cserel (a nem letezot is csereli), soha nem kreal"), ugyanis definíció szerint ha az URI-ben meghatározott elem nem létezik, akkor a szerver (ha képes rá), létrehozhatja az elemet:

"If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request."

Sokan használják a PUT metódust módosításra, viszont azt nem veszik figyelembe, hogy a PUT nem egy-egy értéket módosít, hanem az elem meglévő összes adatát lecseréli a kérésben küldött adattal. Sok esetben nem lehetséges vagy nagyon bonyolult egy ilyen kérést küldeni. Ilyen eset például ha a kliensnek nem áll rendelkezésére az elem az összes adata. Ezért módosításra inkább a PATCH metódust érdemes használni: https://tools.ietf.org/html/rfc5789

Tehát:

Több elem listázása: GET /articles
Egy elem lekérése: GET /articles/1
Elem létrehozása: POST /articles
Elem módosítása: PATCH /articles/1
Elem törlése: DELETE /articles/1

"Sokan használják a PUT metódust módosításra, viszont azt nem veszik figyelembe, hogy a PUT nem egy-egy értéket módosít, hanem az elem meglévő összes adatát lecseréli a kérésben küldött adattal."

A PUT pontosan egy erteket modosit, ha az URI egy adott elemet cimez, illetve az elem osszes erteket, de a lenyeg, hogy kulonbseget kell tenni a kollekcio es egy elem cimzese kozt.

http://en.wikipedia.org/wiki/Representational_state_transfer#Example

Collection URI, such as: http://example.com/resources/

GET List the URIs and perhaps other details of the collection's members.
PUT Replace the entire collection with another collection.
POST Create a new entry in the collection. The new entry's URI is assigned automatically and is usually returned by the operation.
DELETE Delete the entire collection.

Element URI, such as http://example.com/resources/item17

GET Retrieve a representation of the addressed member of the collection, expressed in an appropriate Internet media type.
PUT Replace the addressed member of the collection, or if it doesn't exist, create it.
POST Not generally used. Treat the addressed member as a collection in its own right and create a new entry in it.
DELETE Delete the addressed member of the collection.

en igy hasznalom: subs :-)

--
"Van olyan ember sok az oldalon, akinek a kommentjeinek 100%-a zaj, oket miert nem kommentelitek ilyen lelkesen?" (hrgy84)