News for hackers. Stuff that matters.
Re:Beyond 10,000 Lines: Lessons Learned from a Large Phoenix... by aikah on Wednesday November 09, 2016 @07:18PM (#12916345)
What a total RESTful route to begin with ? I thought REST had nothing to do with "routes", url or resources but how the state of the application is communicated in an API ? It seems to me the Roy wrote something with a certain perspective, someone came up, read the paper and decided to apply his writings to something totally unrelated because he didn't like SOAP ... I personally stopped using that word so I don't have to confront and debate with "REST purists" and just went back to talking about web service, because that's what it is.
Re:Beyond 10,000 Lines: Lessons Learned from a Large Phoenix... by xenadu02 on Thursday November 10, 2016 @02:21AM (#12918409)
As commonly applied it means don't reinvent an RPC+identity+caching+encryption+compression mechanism on top of HTTP because HTTP/S itself is already an RPC mechanism with optional encryption + compression + caching support and URIs provide identity.

HTTP verbs are the operations you wish to perform. GET on a "/" resource is effectively a listing, GET on "/identifier" retrieves a specific item. PUT updates, POST creates new, DELETE is obvious. SOAP was a bad idea because it stuffed an extra RPC layer on top of HTTP's existing layer, requiring you to parse the body to find the content. Thus almost anything interacting with SOAP had to understand both HTTP and SOAP, plain HTTP tools were useless.

HTTP provides out-of-band signaling and extensions with headers. It also has a built-in mechanism to negotiate wire and content formats with Accept/Content-type. All of this means it automatically supports graceful degradation and backwards-compatibility. HTTP is stateless so unless you go out of your way to break that property it scales really well.

URIs identify the resource you want to perform the operation on. Items that are children are located "under" their parents: "/parent/42/childtype/child_id". Again - why introduce some extra system for describing these relationships and identifying resources when URIs already do a fine job of that?

If you want to take it even further you can use URIs in your data types. For example if a child needs to indicate its parent you can provide the parent URI (just the path/query/fragment portion) rather than a parent identifier. Why should the client care how you generate identifiers? It also means you can change them in the future (e.g. Int to String). Hide implementation details of the server from clients when possible.

Re:Beyond 10,000 Lines: Lessons Learned from a Large Phoenix... by aikah on Thursday November 10, 2016 @04:17PM (#12924449)
well articulated and concise explanation. Thank you.
Re:Beyond 10,000 Lines: Lessons Learned from a Large Phoenix... by Arcaire on Wednesday November 09, 2016 @07:22PM (#12916389)
The idea is to limit exposed routes to the standard CRUD routes: create (/new), read (/show), update (/edit), delete (/destroy).
Re:Beyond 10,000 Lines: Lessons Learned from a Large Phoenix... by nardi on Wednesday November 09, 2016 @09:24PM (#12917171)
Ugh, no. The idea is to use standard HTTP verbs (GET, POST, PUT, DELETE) with noun routes, like:

    Create: POST /resources (or PUT /resources/42)  
    Read: GET /resources/42  
    Update: PUT /resources/42 (or PATCH /resources/42)  
    Delete: DELETE /resources/42
    List/Search: GET /resources
Re:Beyond 10,000 Lines: Lessons Learned from a Large Phoenix... by aikah on Wednesday November 09, 2016 @07:32PM (#12916467)
I thought the idea was to make an API behave like a webpage by using hyperlinks that represents the state of the application, so in theory a "smart" client could navigate an API autonomously like a human interacts with a web page ? Because otherwise it's no different from RPC.
Re:Beyond 10,000 Lines: Lessons Learned from a Large Phoenix... by anthonybullard on Wednesday November 09, 2016 @08:25PM (#12916815)
I think you are thinking of HATEOAS. Read about it here: https://en.wikipedia.org/wiki/HATEOAS?wprov=sfla1