Page 2 of 2 FirstFirst 1 2
Results 16 to 18 of 18

Thread: Rest

  1. #16
    SillyMember
    Join Date
    May 2003
    Location
    Gent
    Posts
    7,725
    Quote Originally Posted by GolezTrol View Post
    Of gewoon posten naar /orders en het klantid meegeven in de body.
    Dat is wat ik doe.
    All methodologies are based on fear. -- Kent Beck.

  2. #17
    Wat ik eerder schreef over die arbitraire urls geld ook voor waar je producten op op moet slaan.

    Wanneer je bijvoorbeeld /order/20 opvraagt, dan zou je als resultaat daarvan een stukje json terug kunnen geven met alleen de hoofdinformatie van die order. Verder kan dat resultaat hypermedia links bevatten naar urls om bewerkingen uit te voeren op de order. Zo kan je bijvoorbeeld teruggeven dat iemand iets moet posten naar /3ab55fce-f07b-4d63-9936-5c6b23c1d4a5 om een nieuwe product toe te voegen aan order 20. Wat die code betekent maakt niets uit. Misschien is het een tijdelijke url die alleen geldig is samen met jouw authorisatietoken en alleen tot middernacht. Misschien is het een tijdelijke of nieuwe service die je voor een deel van de orders wil uitproberen.. Het punt is dat je client helemaal niet hoeft te weten wat 'alle' urls van je API zijn. Als je een paar ingangen hebt, zoals het lezen van een order, kan je daarvandaan verder bladeren met hypermedia. En dan is het ook geen vraagstuk meer of het /vagecode of /orders/20/producten of nog wat anders moet zijn, want tenzij het zo'n hoofdingang is, maakt dat dus helemaal niet uit.
    1+1=b

  3. #18
    Quote Originally Posted by Dirk Andries View Post
    I think it is the other way around for REST.
    POST is used on a collection resources to add a child resource. => Create
    PUT is used on a indiviual resource to update. => Update
    I dont know if its "the other way" compared to what I wrote. It all depends on the interpretation of what the URL is and what the data is.
    If the ID is part of the URL, then data POST'ed could be considered child info for the URL.

    However it is all semantics. In real life, POST is more regularly used from HTML forms updating data, than PUT, which in practice can be interpreted in two opposite ways:

    1) Then lets use POST in REST too, because that can be compatible not only with HTML forms but also other REST clients, provided the REST service interprets the transmitted mimetype correctly. This means not having to duplicate functionality for a multihead web server.
    2) Since POST is predominantly used by HTML forms to post data, then by all means do NOT use POST for REST API called from a REST client. Better to have a clean cut.

    I overall prefer 1, but there can easily be cases where 2 is the better choice.

    All in all... the HTTP methods were invented long before REST as such was factored in, and were designed to be used for interactive web and form operations, so not all from those days makes superb sense in relation with REST

Page 2 of 2 FirstFirst 1 2

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •