>>500
お気に入り機能とか使ったことなかった…
タブ170件以上開いて新着チェックしてた

まあそれは置いておいて、
2chmateは使ったことない(IOSだから)よく分からないが、多分専ブラの機能なら大変だろうけどWEBで実装出来ると思う
専ブラ作るのが大変なのはネイティブでも変わらないし

2chは本当WEBページゴミだよな…多分ajaxとかSPAとかが流行ってなかった事に出来たからだと思うけど

明日か明後日にはサーバーサイドAPIの実装が終わるので(テストはまだだけど)、クライアントの方はその後に考えます
とりあえずPushしました

クライアントですがJS使えないブラウザは当然ですが、IEも捨てるかもしれません

いつのまにか500行ってた
テストコード１回も書いたことないから何すればいいか分からん。。。

あとPHP版でコールバック地獄で酷い事になったのでpromise採用します

クライアントはvue.jsではなくangular2を使います

>>302だけど、俺もPHP挫折しそうww
コード補完がまともに動かなったり、->の代わりに.をくせでスペルミスしたりで動かなったり効率悪すぎ。
いちいち、メソッド名忘れると、Webで検索してるわ。
開発環境が悪いのかなぁ・・
Windows上のVisual Studio Codeで作って、仮想マシン上のLinuxにデプロイ・実行してるんだけど。

ということで、.NET Core + ASP.NET Coreに移行中。
とりあえず、開発環境と実行環境分けるとあんまいい感じじゃなさそうなので、
Linux上のVisual Studio Codeでやるわ・・

VS CodeはJSとかHTMLだと軽くて強力だけどPHPは微妙
VSにPHP Tool(クソ高い)入れるかNetBeansおすすめ(そもそもPHPがゴミだけど)

C#ならVS CodeよりVSの無料版の方が絶対良い

>VSにPHP Tool(クソ高い)入れるかNetBeansおすすめ(そもそもPHPがゴミだけど)
勉強目的でいきなりお金払うのわね。NetBeansとかいうのいいんだ。
俺的にはコード補完とかもうちょいまともに効くならPHPという言語でも許容できるけど。

>C#ならVS CodeよりVSの無料版の方が絶対良い
うん。今、それに向けて作業してる。元々、UWPアプリとか作っててVisual Studio 2015使ってるからね。
これ以上、メインマシンをよごしたくなくて、維持でも実行環境(Webサーバー+DBサーバー)は仮想マシン上に構築しようとしてたけど、
Windows上で.NET Core + ASP.NET Coreの開発環境入れてもIISとかインストールされないっぽい(
Kestrelとかいう軽量サーバーがデフォルト？)から、VSにすることにした。
で、データベースだけはLinux上に。

あれ,IIS Expressとかにインストールされちったw

TODO：
User子クラスに認証関係のチェック不足が大量にあったので修正する

API一通り完成したのでコミット＆Pushしましたー

全部POSTメソッドなんだ。
つか、ソース見にくすぎだな。

つか、これ、コンパイルは通ってるの？？
abstract class HttpApiBase(val tokenFlag:TokenFlag,val strParams:List[String],val intParams:List[String]) extends HttpServlet
Scalaの事よくわからんけど、tokenFlagとかコンストラクタの引数？
継承元のHttpServletってサーブレットコンテナ？がHttpServletのインスタンスを生成して、適切なdoPostとかdoGetとか呼んでくれるんじゃないの？
HttpApiBaseにコンストラクタ引数を宣言してて、だれがこれをセットしてくれるのか？？

あ、ごめん。Scalaはなんか違うのか。派生クラスみたら、定数値っぽいのがセットされてるな。

>>514
class Hoge(val i:Int)
は
public class Hoge{
　　public final int i;
　　public Hoge(int i){
　　　　this.i=i;
　　}
}
と同じ(実際は内部でgetterが生成されていたりするけど)
かなり短く書ける

あとListはscalaのAPIで不変なリスト
javaのHoge<T>はScalaではHoge[T]
Hoge[]はArray[Hoge]

あっ大事な事忘れていた
web.xmlがない

URLとかは
hogeFooよりhoge-fooの方がいいのだろうか

RESTfull API的には
hoge/foo/afef
で、HTTPメソッドGETで取得、POSTで挿入、PUTで更新、PATCHで部分更新、DELETEでリソース削除。

>>520
POSTとGETは分かりますが、残りは対応面倒と聞きました
全部POSTに統一が一番シンプルでいいかと思ったので、POSTに統一しています

まだ、バグ修正などありますが、APIを頭の中で整理するために仕様書を書きます

対応って別に全部に対応する必要はないよ。
例えば、User自体は削除できないんだから、Userに対してDeleteメソッドは定義する必要はないし。
Scalaとか使う道具にはこだわるが、作りだす物にはこだわりがないのかね？
いきなり全部はできんけど。

つか、せめて、取得系はGETでいくべきだ。全部POSTとか、クソAPI呼ばわりされること間違いなし。

RESTful APIに別に無理してしなくてもいいが、
例えばQiitaのAPIはRESTful APIっぽいし。
http://qiita.com/api/v2/docs
http://wp.tech-style.info/archives/683

>>523
なるほど
何か難しそうだけどそういう風なのが普通なのか
あとエラーコードの返し方も考えた方がよさそう
全部jsonで返しているし

これHTTPの基礎勉強しないと駄目だ

RESTにしなくても、RPC的なAPIでもいいと。
http://dev.twitter.com/rest/public
Twitterはそんな感じだけど。パラメータの渡し方は。

PATCHとか初めて聞いた

いや、エラーは全部JSONでいいよ。他のResponseとかも
JSONで返すんだし統一性がないと俺ならブチ切れる。

エラーはHTTPのステータスコードでエラーを示して、
更に詳しい情報やメッセージなどをレスポンスのJSONボディで返すのが
普通かな。大手サービスはだいだいこんな感じ。

>>528
エラーの詳細はJSONだろうけど、HTTPステータスがエラーでも200 OK返しているからどうなのかなと思って
例えば、「本文が長すぎます」みたいなのは200 OKでいいの？

>>526のTwitterはGET,POSTでパラメータはどっちかというとクエリパラメータで
渡して、RPC的なんだと思う。

>>529
大まかなエラー内容はHTTPステータスでいいのか

REST APIで調べたら「セッションなどの状態管理を行わない」って書いてあったけどトークンってこれに含まれる？
何か凄く難しい

>>531
twitter参考にしているからこっちがいいのだろうか
何か凄く難しい…
TwitterAPI生では触った事ないから内部でどうなっているか考えた事なかった

>>530
それはまずい、それはクライアラント側のエラーだから
ステータスコードは400のBad Requestで、
JSONの方に、本文が長すぎますみたいな感じで。
まぁ、はじめてなんからほどほどでいいけど。

http://tools.ietf.org/html/rfc7231
で、どんなステータスコードあるかサクっと見たほうがいい。
4xx系がクライアント側のエラー
5xx系がサーバー側。例えば、クライアント側のリクエストには問題ないが、
サーバー側で問題発生で処理できないとか。

>>534
何か基礎が分かってないみたいだからRESTとRPCを見て、エラーコードも確認してみる
実装は明日にする

>REST APIで調べたら「セッションなどの状態管理を行わない」って書いてあったけどトークンってこれに含まれる？
これって認証がらみのトークンだっけ？？
通常は、HTTPのリクエストヘッダにAuthorizationヘッダってあるから
http://tools.ietf.org/html/rfc7235#section-4.2
これで渡してもらうのがふつう。

まぁ、ほんとは認証がらみではOAuth2っていうプロトコルあって、
これをどのサービスを使ってるんだけど。まぁ、さすがに今は覚えることありすぎて
やりすぎかな。

QiitaのAPIもTwitterもFacebookもDropboxもOAuth2だし。みんなこれ使ってる。

Authorizationヘッダとかあったのか
OAuthはTwitterで聞いた事はあるけどよく知らない
HTTPってかなり複雑だったんだな…

やる事が思っていたより多かった

まぁ、俺は何度もHTTPのRFCの仕様を何度もよんだし。
いろいろ大手のAPIを叩いたし、OAuth2のクライアント側も自分で実装したりしたから、
ここらへんは叩き込まれてるけど。あくまでクライアント側だけだから。
>>507で書いたように今はサーバ側を君と一緒に勉強しようとかなと
ここに居座ってるw

一度実装したものを作り直すのは大変だから一回表とかにまとめてみる

>>541
そこだね。見てて思ったんだけど、作り方が水平方向的？なんだよね。
例えば、モデルクラス作るなら、一気に全部モデルクラスを作るみたいな。
これだと、途中で設計まずったときに全部作り直しになるじゃん。
俺なら例えば最初にUserだけのモデル作って、その次は垂直方向にUser用のAPIを作るね。
そうすりゃ、早い段階で問題点に気づけるし、全体像を早い段階で気づける。

アジャイル開発って奴か
クラス間の依存とか考えたら結構難しくて…

認証後回しにしてメインのスレッドとレスポンスからがいいと思う

サブパスワードで安全にしようと考えていたけど、流石に大量のパスワード覚えるのは面倒か
ここ全く考えてなかった

・SubPass廃止
・Tokenの仕様変更
・Storageは1トークン1つ
・GET、POSTメソッドを分ける
・HTTPステータスも返す

そもそも、サブパスでセキュリティで気にするなら
HTTPSを使わんと。
Let's encrypt!!

HTTPSってサーバーの設定じゃない？
サーブレット側でも対応することあるの？

ないと思う。
というよりそういう事いいたかったんじゃなくて、HTTPSはサーバー証明書が
必要になるわけだから、サーバー証明書簡単に取れるのか知らないので
そこらへん気をとめておいてねって言いたかった。

証明書無料のあるか探しておく